Add ParameterNamesModule to "well known" jackson modules

[Sam-Kruglov]

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.

[sdeleuze]

ParameterNamesModule looks useful for common use case, so I will merge those changes.

I will raise your point about enabling service loader instead with the team. Well-know modules can be enabled via this mechanism so if it does not introduce side effects, that could indeed be an alternative.

[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.

[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.

[bclozel]

@floatdrop See spring-projects/spring-boot#40036 for a case that sounds close to yours.

[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.

[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