Skip to content

Conversation

@wpalmeri
Copy link

This will ensure that the custom OptionDeserializer is always used when deserializing Options.
Right now when List[Option[_]] is deserialized, the Option class is treated as a "simple" type in the constructed JavaType and thus a generic JSON Deserializer is used rather than OptionDeserializer.
Note that the new test will NOT pass until a jackson-databind dependency with FasterXML/jackson-databind#407 is used

This will ensure that the custom OptionDeserializer is always used when deserializing Options.
Right now when `List[Option[_]]` is deserialized, the Option class is treated as a "simple" type in the constructed `JavaType` and thus a generic JSON Deserializer is used rather than `OptionDeserializer`.
Note that the new test will NOT pass until a jackson-databind dependency with FasterXML/jackson-databind#407 is used
@cowtowncoder
Copy link
Member

@christophercurrie now that we have a CLA and merged issue 407 (for master), should be possible to proceed with this one.

@cowtowncoder
Copy link
Member

Ah. Right, I forgot that this was submitted to mainline, and no merging back to 2.3... :-(

@wpalmeri
Copy link
Author

wpalmeri commented Mar 4, 2014

My bad guys, wasn't aware. Perhaps some PR best practices should be added to to the main repo?

@arschles
Copy link

@cowtowncoder is this change released in a version?

@cowtowncoder
Copy link
Member

@arschles I'll defer to @christophercurrie on that question; 2.4.0 of scala module is not out yet.

@arschles
Copy link

k, thanks

@christophercurrie
Copy link
Member

It should go out with 2.4; that's been delayed by personal time constraints but the target is to get it out by the end of next week.

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

Successfully merging this pull request may close these issues.

4 participants