Previously, the default client and server HTTP message converter
customizers were ordered with lowest precedence. This made it
impossible to guarantee that another customizer would be able to go
after the default customizers, preventing their customizations from
being reliably overridden.
This commit updates the definitions of the default customizers to
order them at 0. This allows additional customizers to be ordered
either before or after them. Usage of the customizers is now always
ordered (previously Spring MVC's was not).
See gh-47798
Simplify HTTP client configuration properties by sharing common
settings for both blocking and reactive clients.
The `ClientHttpRequestFactorySettings` and `ClientHttpConnectorSettings`
have been merged to a single `HttpClientSettings` class. Properties
to configure common settings are available under:
`spring.http.clients`
Blocking and reactive settings have been moved to
`spring.http.clients.blocking` and `spring.http.clients.reactive`. With
currently only the factory/connector being configurable.
HTTP Service Client properties have also been rationalized under a
`spring.http.serviceclient.<group-name>`. Support for properties that
apply to all service clients and all Rest/Web Clients have been removed.
Support for `ApiVerionInserter` beans has also been removed in favor of
configuring the service group or builders directly.
Closes gh-47398
Create `spring-boot-resttestclient` and `spring-boot-webtestclient`
modules to hold test client auto-configuration and `TestRestTemplate`
code.
Previous these classes were contained in `spring-boot-resetclient-test`
and `spring-boot-webclient-test` which was incorrect since the `-test`
modules should hold code need to test the given modules, not supporting
test classes.
See gh-46356
Co-authored-by: Phillip Webb <phil.webb@broadcom.com>
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>
Update service client configuration so that properties are always
applied when present. Any settings and factory/connector beans that
are present are now only used as fallbacks.
Fixes gh-46915
Refactor `HttpServiceClientAutoConfiguration` and
`ReactiveHttpServiceClientAutoConfiguration` to support scanning for
`@HttpServiceClient` annotated interfaces.
Closes gh-46782
The enum itself is not specifically tied to auto-configuration so
spring-boot is a better place for it. The related condition,
`@ConditionalOnThreading`, remains in spring-boot-autoconfigure. This
aligns things with the similar `CloudPlatform` and
`@ConditionalOnCloudPlatform`.
Closes gh-46406
Stéphane Nicoll
Phillip Webb
Andy Wilkinson
Moritz Halbritter
Brian Clozel