Remove spring-boot-json-test module and spread code between
`spring-boot-test`, `spring-boot-test-autoconfigure` and JSON
technology modules.
See gh-46356
See gh-47322
Make `spring-boot-test-autoconfigure` optionally depend on
`spring-boot-autoconfigure` so that it can be an `api` dependency
for `*-test` modules. Also relocate it to core.
See gh-47322
Move `@PropertyMapping` and supporting code from the
`spring-boot-test-autoconfigure` module to `spring-boot-test`
since it's generally applicable.
See gh-46356
See gh-47322
Move `@TypeExcludeFilters` and supporting code from the
`spring-boot-test-autoconfigure` module to `spring-boot-test`
since it's generally applicable.
See gh-46356
See gh-47322
This commit modularizes spring-boot-test-autoconfigure. It now
contains only the code that's central to test auto-configuration.
Feature-specific functionality has moved out into -test modules,
some existing and some newly created. For example, `@DataJpaTest` can
now be found in spring-boot-data-jpa-test.
Closes gh-47322
This commit removes all mentions of JUnit 4 from the Javadoc and
reference documentation. It also harmonizes to simply refers to JUnit.
Closes gh-47228
Drop `isImmutable` and `getPrefix` from `OriginLookup` since
they're not really Origin concerns. Now that `env` is a
foundational layer we can add a dedicated `PropertySourceInfo`
interface and add that to the `o.s.b.env` package without
creating a package tangle.
Closes gh-45547
Move `AnsiOutputApplicationListener` from `o.s.b.context.config`
to `o.s.b.support` since it's more of a supporting class than a
context concern.
See gh-47232
Move `DefaultPropertiesPropertySource` from
`org.springframework.boot` to `org.springframework.boot.env` since
it's not directly tied to `SpringApplication`.
See gh-47232
Move the `EnvironmentPostProcessor` from `org.springframework.boot.env`
to `org.springframework.boot` so that we can make the `env` package
foundational.
Most `EnvironmentPostProcessor` implementation has also been relocated
to a new `org.springframework.boot.support` package.
See gh-47232
Move bootstrap code from `org.springframework.boot` to
`org.springframework.boot.bootstrap` and make them a foundational
layer.
This move helps reduce `org.springframework.boot.context.config`
dependencies to `org.springframework.boot`.
See gh-47232
This commit adds a spring-boot-persistence module with data technology
independent features. This provides a better home for EntityScan and
PersistenceExceptionTranslationAutoConfiguration.
Closes gh-45328
Update `ConfigDataLocation.of` to return an empty location rather than
null. Filtering of empty elements now happens in `ConfigDataProperties`
and `ConfigDataEnvironment` which allows us to simplify
`ConfigDataLocationBindHandler`.
Closes gh-47221
Co-authored-by: Phillip Webb <phil.webb@broadcom.com>
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>
Phillip Webb
Stéphane Nicoll
Andy Wilkinson
Moritz Halbritter
Yanming Zhou
Piotr P. Karwasz