Also, I'm surprised to see that org.springframework.http.converter.json.Jackson2ObjectMapperBuilder#findModulesViaServiceLoader is not true by default. Why not always just let it scan the classpath, seems like findWellKnownModules does the same but manually.
Comment From: sdeleuze
Notice such change was also discussed in #17886, and at that time we decided to not include it, but nowadays I expect developers to use much more constructor binding, so using this default makes sense. Inclusion in the Release Candidate will give us the opportunity to revise that choice if we have feedback mentioning unwanted side effects.
Comment From: floatdrop
Jesus, this is kind of breaking change. This module can cause 415 error, because now some classes can have "Conflicting/ambiguous property name definitions" and default deserializer will fail to parse request.
Comment From: bclozel
@floatdrop See spring-projects/spring-boot#40036 for a case that sounds close to yours.
Comment From: floatdrop
@floatdrop See spring-projects/spring-boot#40036 for a case that sounds close to yours.
Kind of the same – we have some classes with @JsonProperty in constructor as well as @JsonProperty on properties plus public getters, that cause name conflicts when ParameterNamesModule is autoinjected in deserializer.
Excluding jackson-module-parameter-names from modules temporary fixes the issue.
Comment From: Sam-Kruglov
@floatdrop hey, unless you want property names to appear different in json than they are in the pojo, you can just delete those annotations. Jackson can just read constructor parameter names and getters via reflection. Never had a problem like that