-
-
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
findImplicitPropertyName and setPropertyNamingStrategy change from 2.6.4 to 2.7.0 #1077
Comments
It looks like I can work around this by configuring |
Possibly same root cause as #1076, but will keep open, see if tackling that helps here. |
@michaelhixson Actually, I think behavior is as expected here: since annotations you specify are explicit naming, they are not (by default) sent to naming strategy for renaming. But you can change the behavior using |
Also note #926 which gives more control via |
@cowtowncoder I'm fine with closing this then, since there's a simple workaround for me. |
@michaelhixson Ok thanks. I can see why behavior might be unexpected, too, since there is slight semantic of difference between Thank you for reporting this: it is possible others may bump into it as well. |
@cowtowncoder Your comment confused me. You have built-in support for sees #905... Hooray! |
@michaelhixson Ah. Sorry, I thought you were involved in that issue... :) It was #905, and yes, is now included in 2.7. |
I use a custom
AnnotationIntrospector
that reads thejava.beans.ConstructorProperties
annotation on constructors. It figures out the mapping from JSON fields to constructor arguments. This code worked in 2.6.4 but broke in 2.7.0, with respect to its interaction withPropertyNamingStrategy
.Here's a sample unit test that used to pass but now fails:
In case it matters, the use case for that custom
AnnotationIntrospector
is enabling deserialization of Lombok@Value
classes. https://projectlombok.org/features/Value.htmlThe text was updated successfully, but these errors were encountered: