-
-
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
configOverrides(boolean.class) silently ignored, wheres .configOverride(Boolean.class) works for both primitives and boxed boolean values #3080
Comments
Quick check: the usual way to refer to primitive If not, this does sound like a bug, and if so possibly simple one. |
Ok, yes, I can reproduce this. Before looking at the fix, this does cause a problem since the way this should work (as per design) is as per (3): Jackson does (or at least attempts :) to) distinguish between primitive and wrapper types; and so current behavior is incorrect. Problem here is that changing this now is API changing as the problem was not caught before 2.12.0 release. In theory I could try to specify defaulting of some sort (so that setting for So. I think I'll work towards fixing this for 2.13.0. |
The bug itself is simple; in
regardless of whether this is serializer for primitive or wrapper. Easy to fix in and of itself, but think I'll check to see how number serializers work. And perhaps even see how tricky defaulting might be; if simple enough, could add it only in here and remove from 3.0 ( |
Fixed for 2.13.0: I would recommend setting shape for both wrapper and primitive, even with 2.12, for future-proofing. |
wow, that was fast! Many thanks! |
@asaf-romano sometimes this happens, but it is not necessarily representative of the typical bug report experience :) (obv. disclaimer). That said, thank you for reporting this! |
Using version 2.12:
This works as expected. Boxed Boolean values are serialized as 1/0. Moreover, it also works for primitive booleans.
However,
seems to do nothing, for either types.
I find this behavior quite surprising. I think it's reasonable to assume any of the following:
boolean
impliesBoolean
symmetricallyboolean
impliesBoolean
, but not the other way around (mirroring the current behavior)The text was updated successfully, but these errors were encountered: