-
-
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
StringCollectionDeserializer
fails with custom collection
#2324
Comments
Here is the unit test code that reproduces the problem. Only
|
Workaround (understandably, less than desirable): nail the custom deserializer through the
|
Thank you for reporting this: seems like a bug. |
Interesting. I can reproduce the issue as presented, and the problem seems to be with Jackson's special handling for |
Interesting. This may be due to #1010 which added separation between "regular" and "array delegator" creators -- that would have been 2.7.0. We occasionally find places where only former is supported (since earlier there wasn't array variant). |
StringCollectionDeserializer
fails with custom collection
@cowtowncoder, thanks, I appreciate the quick turnaround. Please let me know if you need any help with validating the fix. Meanwhile here is slightly improved (although longer) version of the workaround that handles edge cases (like raw types and situations where the collection argument type cannot infer from context) better:
This can be used as follows:
|
Ok. Just to make sure: I don't think you should need to do any of this, as long as deserializer is accessed via |
Seeing this with Jackson 2.9.8.
We have a custom collection implementation, which is wired to use its "immutable" version for deserialization. The rationale is that we don't want accidental modifications to the data structures that come from the wire, so they all are forced to be immutable.
After upgrade from 2.6.3 to 2.9.8, the deserialization started breaking with the message:
This happens ONLY when you deserialize a custom collection of strings as a property of the other object. Deserializing the custom collection of strings directly works fine, and so does the deserialization of custom collection of non-strings. I believe either the
StringCollectionDeserializer
should not be invoked for custom collections, or perhaps it does not handle the delegation as expected.Please see comments for repro and workaround.
Thanks!
The text was updated successfully, but these errors were encountered: