Skip to content
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

Closed
ljnelson opened this issue Jan 26, 2015 · 6 comments
Milestone

Comments

@ljnelson
Copy link

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 target Class 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.

cowtowncoder added a commit that referenced this issue Apr 3, 2015
@cowtowncoder cowtowncoder added this to the 2.6.0 milestone Apr 3, 2015
@cowtowncoder
Copy link
Member

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).

@ljnelson
Copy link
Author

ljnelson commented Apr 3, 2015

Beautiful; thanks!

@cemo
Copy link

cemo commented Apr 9, 2015

@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 MixInResolver? Right? I am dying for this feature :)

@cowtowncoder
Copy link
Member

@cemo Yes exactly, that is the idea here. Just implement MixInResolver.

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.

@cemo
Copy link

cemo commented Apr 9, 2015

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:

abstract class MixIn {
  MixIn(@JsonProperty("width") int w, @JsonProperty("height") int h) { }

  @JsonProperty("width") abstract int getW(); // rename property
  @JsonProperty("height") abstract int getH(); // rename property
  @JsonIgnore int getSize(); // we don't need it!

}

a new property such as area can easily be added to it. :) Should I open a new ticket?

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.

@cowtowncoder
Copy link
Member

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 @JsonAppend (and underlying functionality that allows injection of virtual properties via other routes). Those may be added via mix-ins.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants