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

delegate deserializers choke on a (single) abstract/polymorphic parameter, where a named property works fine #580

Closed
tea-dragon opened this issue Oct 14, 2014 · 7 comments
Milestone

Comments

@tea-dragon
Copy link
Contributor

assuming this works (ie. the abstract type has type deserialization configs):

@JsonCreator public SomeClass(@JsonProperty("source") SomeAbstractClass source) {}

this still does not work:

@JsonCreator public SomeClass(SomeAbstractClass source) {}

the former has slightly different syntax since the delegate object has to be wrapped in another property, but I am drawing a blank as to why this would be intentionally inconsistent. It seems to be an issue where delegate deserializers fail to do any logic related to type resolution and fail on an AbstractDeserializer.deserialize() call.

@cowtowncoder
Copy link
Member

There is no intentional non-support, but given complexity of dealing with combination of polymorphic types and creators, there may be a loose end or two.
I'll have a look to see what is missing/not-working.

cowtowncoder added a commit that referenced this issue Oct 14, 2014
@cowtowncoder
Copy link
Member

I can reproduce this issue; added a (failing) test. Hopefully can figure out, fix, for 2.5.0 at least (ideally 2.4 too but we'll see how much changes are needed)

@cowtowncoder cowtowncoder added this to the 2.2 milestone Oct 15, 2014
@cowtowncoder
Copy link
Member

Turns out it's sort of... common problem. Due to way polymorphic types need matching TypeDeserializer, code needs to handle this explicitly, and that was missing from delegating case.
I suspect there may be similar cases remaining elsewhere; but they are difficult to find in generic manner.
At any rate, this particular problem is now resolved near as I can see: definitely for 2.5 (with test), but also for 2.4.4.

@tea-dragon
Copy link
Contributor Author

Awesome! I have to say I did not have high hopes because it did seem sort of not-well-supported by the rest of the inner workings. Thanks. Looking forward to this one.

@christophercurrie
Copy link
Member

I suspect another of the remaining cases is the one I just filed as FasterXML/jackson-module-parameter-names#10.

@cowtowncoder
Copy link
Member

@christophercurrie I think a test that does not rely on parameter names module would be needed since I am not sure I yet understand what is failing based on other description.

@cowtowncoder
Copy link
Member

Sorry, actually I can see the tests, makes sense. Thanks!

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