This commit adapts the auto-configuration of AMQP message listeners
and RabbitTemplate moving away from Spring Retry.
One important change is that message listeners now only require a
RetryPolicy. To make the callback explicit, two customizers have been
introduced to clearly separate the scope of the customization:
* RabbitTemplateRetrySettingsCustomizer for the client-side and usage
of RabbitTemplate.
* RabbitListenerRetrySettingsCustomizer for message listeners.
Closes gh-47122
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>
Log4j Core 3 has undergone significant modularization and no longer uses
optional parser dependencies. This change requires updates to
Spring Boot's configuration file detection logic to properly support
both Log4j Core 2 and 3.
**Updated configuration file detection**
Spring Boot now detects configuration formats based on the presence of
ConfigurationFactory implementations, instead of relying on optional
parser dependencies (as was the case in Log4j Core 2).
**Improved classloader usage for reflection**
Reflection logic now uses the classloader that loaded Log4j Core,
rather than the one associated with the Spring Boot context,
ensuring greater compatibility in modular environments.
* **Adjusted configuration file lookup order**
The lookup now prioritizes configuration files specified via
properties over automatically discovered ones, improving consistency
with Log4j Core.
**Support for contextual configuration files**
Files named in the form `log4j2<contextName>.<extension>` are now also
supported.
These changes ensure compatibility with Log4j Core 3 while preserving
support for Log4j Core 2, improving Spring Boot's flexibility in
detecting and loading user-defined logging configurations.
See gh-46409
Signed-off-by: Piotr P. Karwasz <piotr@github.copernik.eu>
This commit aligns the file charset between Log4j2 and Logback.
Prior to this commit, there was an inconsistency between the two: Log4j2
used UTF-8, while Logback used Charset.defaultCharset(), which is
platform-dependent.
See gh-46846
Signed-off-by: Dmytro Nosan <dimanosan@gmail.com>
Projects which don't have JSpecify nullability annotations can opt out
by using
architectureCheck {
nullMarked = false
}
in their build.gradle script.
See gh-46587
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
Moritz Halbritter
Phillip Webb
Andy Wilkinson
Piotr P. Karwasz
Volkan Yazıcı
Dmytro Nosan