-
-
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
DeserializationProblemHandler is not working with wrapper type when returning null #3450
Comments
Thank you for reporting this issue. I cannot say off-hand whether Thank you for including unit tests. |
I have finally found a workaround by doing the following in my model
Changing the setter parameter to a Number indicates to Jackson to use the NumberDeserializer instead of the IntegerDeserializer. The NumberDeserializer returns the result of the method handleWeirdStringValue without altering it which solves my issue. |
Ok, yes, this is a bug @LJeanneau -- caused by calling "primitive" handler where it really isn't one. |
Fixed for 2.14.0 -- theoretically could also backport into 2.13(.3). |
Backport in 2.13 branch for 2.13.3 release. |
Thanks for the fix ; tested with success on my scenario in 2.13.3 |
Describe the bug
Overriding handleWeirdStringValue method of DeserializationProblemHandler and returning null as a default value for a wrapper type (Integer in my case) is not working and is changed to 0 during deserialization
It seems to me that this is due to _parseInteger method using _parseIntPrimitive in StdDeserializer and I can't figure out a way to workaround this behavior. Trying to use an optional leads to Optional.of(0) being returned.
Version information
Bug has been observed in 2.13.2.2 ; was previously working with 2.10.2
To Reproduce
Expected behavior
Expected behavior is deserializing null instead of 0 as requested by DeserializationProblemHandler as null is a valid value for Integer
The text was updated successfully, but these errors were encountered: