-
-
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
delegate deserializers choke on a (single) abstract/polymorphic parameter, where a named property works fine #580
Comments
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 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) |
Turns out it's sort of... common problem. Due to way polymorphic types need matching |
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. |
I suspect another of the remaining cases is the one I just filed as FasterXML/jackson-module-parameter-names#10. |
@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. |
Sorry, actually I can see the tests, makes sense. Thanks! |
assuming this works (ie. the abstract type has type deserialization configs):
this still does not work:
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.The text was updated successfully, but these errors were encountered: