Prior to this commit, the `HttpMessageConverters` auto-configuration
would pick up `HttpMessageConverter<?>` beans from the context and
broadly apply them to both server and client converters setup.
This can cause several types of problems.
First, specific configurations only meant for server setup will also be
applied to the client side. For example, the Actuator JSOn configuration
is only meant to be applied to the server infrastructure.
Also, picking up converters from the context does not convey whether
such converters are meant to override the default ones or should be
configured as custom, in addition to the defaults.
For example, a bean extending `JacksonJsonHttpMessageConverter` can be
both meant to override the default with `builder.withJsonConverter` or
meant as an additional converter with `builder.addCustomConverter`.
This commit ensures that the auto-configurations contribute
`ClientHttpMessageConvertersCustomizer` and
`ServerHttpMessageConvertersCustomizer` beans instead of converter beans
directly. Applications can still contribute such beans and those will be
used.
Fixes gh-48310
Prior to this commit, Spring Boot had an `HttpMessageConverters` class
that allowed, to configure message converter instances for MVC server
applications and traditional Spring HTTP clients.
As of Spring Framework 7.0, Framework ships its own
`HttpMessageConverters` class, aligning with the existing codecs
configuration on the WebFlux side. As a result, a few methods taking
`List<HttpMessageConverter>` as arguments were deprecated in favor of
the new arrangement.
This commit adapts to the Framework changes by deprecating Boot's
`HttpMessageConverters` in favor of Framework's. This splits the client
and server configuration as they are meant to be managed separately.
Applications can still contribute `HttpMessageConverters` (Boot's
variant) beans but the type itself is now deprecated.
Instead, applications should now contribute
`ClientHttpMessageConvertersCustomizer` and
`ServerHttpMessageConvertersCustomizer` beans to customize message
converters.
Closes gh-46411
Refactor `PropertyMapper` so that it no longer calls adapter or
predicate methods by default when the source value is `null`. This
effectively makes all default calls the same as using
`alwaysWhenNotNull` in the previous generation of the code.
For the limited times when you do need to deal with `null` values, the
new `always()` method can be used.
For example,
map.from(source::method).to(destination::method);
Will not call `destination.method(...)` if `source.method()` returns
`null`.
Where as:
map.from(source::method).always().to(destination::method);
Will call `destination.method(null)` if `source.method()` returns
`null`.
This update provides clearer semantics for the API and allows for better
JSpecify nullability annotations. It has also simplified much of our
existing property mapper code.
Closes gh-47024
Co-authored-by: Moritz Halbritter <moritz.halbritter@broadcom.com>
Brian Clozel
Andy Wilkinson
Phillip Webb
Moritz Halbritter
Stéphane Nicoll