With Spring Framework 7.1 deprecating RestTemplate for removal, this
commit deprecates our supporting infrastructure as well, and steers
users towards RestClient instead:
* RestTemplateAutoConfiguration and
RestTemplateObservationAutoConfiguration
* RestTemplateBuilder, RestTemplateBuilderConfigurer, and
RestTemplateBuilderClientHttpRequestInitializer
* RestTemplateCustomizer, RestTemplateRequestCustomizer, and
ObservationRestTemplateCustomizer
* MockRestServiceServerAutoConfiguration,
MockServerRestTemplateCustomizer, and RootUriRequestExpectationManager
in the test support module
The reference documentation no longer covers RestTemplate and now
solely documents RestClient and WebClient. Code snippets and sample
tests that only existed to illustrate RestTemplate usage have been
removed accordingly.
Closes gh-51118
This commit adds auto-configuration for the generic AMQP 1.0 client
in Spring AMQP 4.1, using Qpid ProtonJ. Support for connection factory,
client and listener endpoints are available.
The "spring.amqp" namespace exposes settings to connect to an AMQP 1.0
compliant broker and customize client and listeners settings. Docker
compose and testcontainers support using RabbitMQ, ActiveMQ, and Artemis
have been added too.
Closes gh-49678
Now that Spring AMQP supports AMQP 1.0 as well, we need to straighten
out our existing support. AMQP 0.9 is RabbitMQ specific, so we can no
longer refer it to "amqp". This commit migrates the existing support
to spring-boot-rabbitmq and renames the starters as well.
For continuity, users should migrate from "spring-boot-starter-amqp"
to "spring-boot-starter-rabbitmq". While the root package has been
changed for consistency, most names are the same, including
configuration properties still in the "spring.rabbitmq" namespace.
Keys to configure the version of the RabbitMQ clients have migrated to
'rabbitmq.client' and 'rabbitmq.stream.client' respectively.
Closes gh-49677
Add `InetAddressFilter` interface which can be provided by
`HttpSettings` to filter out addresses in order to harden
applications against SSRF attacks.
Closes gh-49687
This commit adds support for `@RedisListener` by providing the
infrastructure to register those endpoints using a default
`RedisMessageListenerContainer`.
Users wishing to configure additional containers can benefit from
`RedisMessageListenerContainerConfigurer`. The default container can
be tuned using new properties in the `spring.data.redis.listener`
namespace.
Closes gh-49858
This commit adds auto-configuration for the generic AMQP 1.0 client
in Spring AMQP 4.1, using Qpid ProtonJ. The auto-configuration provides
an AmqpConnectionFactory as well as an AmqpClient with standard
customizer callbacks. The "spring.amqp" namespace exposes settings to
connect to an AMQP 1.0 compliant broker. Docker compose and
testcontainers support using RabbitMQ have been added too.
Closes gh-49621
Update the `Binder` so that empty properties are treated as an indicator
that default value binding should be attempted. This update allow bound
objects to differentiate between a completely missing property vs one
that is present but doesn't have any values.
For example, given the following value object:
@ConfigurationProperties("my")
public record My(Name name, int age) {
public record Name(String first, String last) {
}
}
The following binding scenarios are supported:
1) Full binding
my.name.first=Spring
my.name.last=Boot
my.age=4
Binds to `new My(new Name("Spring", "Boot"), 4)`
(works the same as Spring Boot 4.0)
2) Missing Properties
my.age=4
Binds to `new My(null, 4)`
(works the same as Spring Boot 4.0)
3) Default Properties
my.name=
my.age=4
Binds to `new My(new Name(null, null), 4)`
(previously would throw a converter exception)
Closes gh-48920
This commit updates the reference documentation to better reflect
changes applied in gh-48310. As of Spring Boot 4.0.1,
`HttpMessageConverter` beans are all considered as "custom" converters
and will be set ahead of the converters list in the auto-configuration
support.
For more specific changes, developers should contribute
`ClientHttpMessageConvertersCustomizer` or
`ServerHttpMessageConvertersCustomizer` beans to better reflect their
intent: should the converter be configured for client, server or both?
How should this converter be used?
Previously, Spring Boot was relying on heuristics but they would cause
issues for server-only converters, or for specific configuration that
were not meant to replace the default converter for a given media type.
Closes gh-48574
Stéphane Nicoll
Alexander Makarov
Brian Clozel
Eddú Meléndez
Venkata Naga Sai Srikanth Gollapudi
Andy Wilkinson
Phillip Webb
Moritz Halbritter
jwalter