On Wed, Jan 23, 2019 at 6:58 AM Rich MacDonald <[email protected]> wrote:
>
> The essence of the problem is that I have a large (several thousand) class
> hierarchy without an empty constructor. Since @JsonCreator does not apply to
> subclasses, I would have to add the @JsonCreator and @JacksonInject to every
> subclass. The following would work:
Yes, but it was bit unclear as to how how `@JsonCreator` could even
theoretically apply to sub-classes, as unlike methods they are not
overridable. Although I guess in theory one could maybe consider that
signatures need to match (and internal "name" constructors have is
actually the same).
Thank you for explaining the problem: it makes sense.
One of follow-up thoughts would be use of mix-in annotations, where
you could dynamically add overrides.
And since you can reuse single mixin class to any number of targets
(as long as constructor signature matches), you could relatively
easily register large number of associations.
But we can do better: consider that all annotation introspection
occurs through `AnnotationIntrospector`: by default,
`JacksonAnnotationInstropector` is used and it uses standard
annotations.
Custom implementations (whether extending JAI or not) may, however,
use whatever source they want. So, you would want to override:
public JsonCreator.Mode findCreatorAnnotation(MapperConfig<?>
config, Annotated a) { ... }
to return `JsonCreator.Mode.PROPERTIES` for specific constructor you'd
like to be used.
Effect would be same as actually adding `@JsonCreator(mode =
Mode.PROPERTIES)` on that constructor.
Could this work here?
If not, I think `ValueInstantiator` can be made to work too, but it's
bit more work.
-+ Tatu +-
>
> class TestDomain {
> //no empty-argument constructor
>
> @JsonCreator
> public TestDomain(@JacksonInject("constructor1") Object
> consAttr1) {
> //code
> }
> }
> //subclass with identical constructor
> class TestDomainSub extends TestDomain {
> @JsonCreator
> public TestDomain(@JacksonInject("constructor1") Object
> consAttr1) {
> super(consAttr1);
> //code
> }
> }
> //several thousand more subclasses, none of which are annotated
>
>
> The problem is that I can't go back and add the necessary @JsonCreator and
> @JacksonInject annotation to so many existing subclasses. Too much work and
> unnecessary boilerplate.
>
> If @JsonCreator had an "applyToSubclasses=true" boolean property, that would
> solve the problem perfectly.
>
> I understood the initial arguments for not applying @JsonCreator to
> subclasses. However, there are common simple situations like the above where
> it would be the best solution: In this case, the entire class hierarchy has
> exactly the same constructor pattern, so a single definition would suffice.
>
> I have no need for a custom deserializer with the single exception of needing
> to replace the instantiation.
>
> Rich MacDonald
>
> --
> You received this message because you are subscribed to the Google Groups
> "jackson-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"jackson-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
For more options, visit https://groups.google.com/d/optout.
