-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: Provide a means for an ObjectMapper to discover mixin annotation classes on demand #688
Comments
As per commit message, finally found time to implement. By default it is possible to specify both direct mappings (lower precedence) and separate custom resolver (higher precedence). |
Beautiful; thanks! |
@cowtowncoder Is this means that I can extend a class and add easily properties on the fly with mixin? It seems that I just need to set a custom |
@cemo Yes exactly, that is the idea here. Just implement How well it works depends on the use case I imagine, for now assumption is that there is actual class to take annotations from -- would be great to make that more dynamic, but one step at a time. |
It would be awesome to have a feature to include MixIn properties which are not present on actual class. For example documentation of mixin has an example:
a new property such as This feature will be really very nice addition. Even a mixin class can extend actual class and add new properties on the fly. Extending provides not only IDE simplifications for refactoring but also easy to new properties. |
I am not sure I follow how mix-ins could add new properties -- all they can do is to add annotations to existing members of actual classes. No code from mix-ins is added or invoked; that would require bytecode manipulation. Mix-in classes are never used in any other way; being class definitions and not instances, they have no state. So what would values of such virtual properties be? Jackson 2.5 did add possibility of virtual properties, on the other hand, with |
In a large, maturing application, it is burdensome to have to store in some central location a list of all the possible mixin classes and their target classes (and then to keep that list up to date).
Adding mixin classes on demand can be thread-unsafe or "too late" in certain circumstances.
Instead, consider a callback-based mechanism or something similar, where a mixin class provider can be queried for the appropriate mixin
Class
to use for a given targetClass
that is about to be serialized. That way, Jackson can be in full control as to when this happens, while the mixin class provider can be in full control over how such a mixin class is located and loaded.http://fasterxml.github.io/jackson-databind/javadoc/2.4/com/fasterxml/jackson/databind/introspect/ClassIntrospector.MixInResolver.html might be a good starting point.
The text was updated successfully, but these errors were encountered: