Previously, actuator endpoints were registered with Jersey upon
injection of the ResourceConfig bean into a registrar class rather than
using a ResourceConfigCustomizer. This was done to fix a problem
when running the Actuator on a separate port where the main application
context's customizers were also applied to the management context,
breaking the singleton contract for those resources. This approach
meant that the registration could be performed at any point after the
ResourceConfig had been created. When Jersey's configured as a Filter
this resulted in the registration failing as the attempt was being made
after the Filter lifecyle callbacks which make the ResourceConfig
immutable.
This commit reworks the endpoint registration to be performed using a
ManagementContextResourceConfigCustomizer, a resource config customizer
that's only applied to the ResourceConfig that's used by the Actuator.
When there's a separate management context, this ResourceConfig is
created by the Actuator's auto-configuration and the management context
resource config customizers are applied to it during its creation. The
main application's customizers are not applied. When the actuator is
using the same context as the main application, this ResourceConfig is
created by the main application. In this case a
ResourceConfigCustomizer is defined that delegates to all
ManagementContextResourceConfigCustomizers, allowing them to register
the actuator endpoints with the main ResourceConfig.
Fixes gh-25262
Previously, DataSource initialization was triggered via a
BeanPostProcessor or a schema created event from JPA. This caused
numerous problems with circular dependencies, bean lifecycle, etc and
added significant complexity.
This commit reworks DataSource initialization to remove the use of a
BeanPostProcessor entirely. In its place, DataSource initialization is
now driven by an InitializingBean with dependency relationships
between beans ensuring that initialization has been performed before
the DataSource is used. This aligns with the approach that's worked
well with Flyway and Liquibase.
More changes are planned to further simplify DataSource initialization.
The changes in this commit are a foundation for those changes. Any new
public API in this commit is highly likely to change before the next
GA.
Fixes gh-13042
Fixes gh-23736
Update `build.gradle` files to ensure that `junit-platform-launcher` is
a `testRuntimeOnly` dependency. This ensures that tests can be run from
Eclipse.
Closes gh-25074
Exclude `@ConfigurationProperties` beans from method validation so
that `@Validated` can be used on final classes without the method
validation post-processor throwing an exception.
This commit introduces a `FilteredMethodValidationPostProcessor` class
which will use `MethodValidationExcludeFilters` to exclude beans from
method validation processing. Using `@EnableConfigurationProperties`
will automatically register an appropriate filter.
Closes gh-21454
Replace `WebSecurityConfigurer` and `WebSecurityConfigurerAdapter`
configurations with `WebSecurityCustomizer` or `SecurityFilterChain`
beans.
Closes gh-23421
Previously, the base path of a servlet-based management server could be
configured using management.server.servlet.context-path but there was no
equivalent property for WebFlux.
This commit introduces a new property, management.server.base-path,
that can be used with both servlet and reactive management servers. The
existing servlet-specific property has been deprecated in favour of the
new general property. When using the servlet stack, if both the general
property and the servlet-specific property are set, the new general
property takes precedence. When using the reactive stack, only the new
general property is considered.
Closes gh-22906
Refactor `ConfigData` processing code to make it less awkward to
follow.
Prior to this commit the `ConfigDataLocationResolver` would take a
String location and return a `ConfigDataLocation` instance. This was
a little confusing since sometimes we would refer to `location` as the
String value, and sometimes it would be the typed instance. We also
had nowhere sensible to put the `optional:` prefix logic and we needed
to pass a `boolean` parameter to a number of methods. The recently
introduced `Orgin` support also didn't have a good home.
To solve this, `ConfigDataLocation` has been renamed to
`ConfigDataResource`. This frees up `ConfigDataLocation` to be used
as a richer `location` type that holds the String value, the `Orgin`
and provides a home for the `optional:` logic.
This commit also cleans up a few other areas of the code, including
renaming `ResourceConfigData...` to `StandardConfigData...`. It also
introduces a new exception hierarchy for `ConfigDataNotFoundExceptions`.
Closes gh-23711
Constructor calls like new AtomicInteger(0) cause a volatile write that
can be saved in cases where the constructor parameter is the default
value.
See gh-23575
Previously, the default servlet was registered automatically when using
embedded Jetty, Tomcat, or Undertow. However, it is not used by the
majority of applications where Spring MVC's DispatcherServlet will be
the only servlet that's needed. As such configuring the default servlet
was wasting CPU and memory.
This commit changes the default for registering the default servlet to
false. It can be re-enabled by setting
server.servlet.register-default-servlet=true.
Closes gh-22915
Refactor `BootstrapRegistry` support following initial prototype work
with the Spring Cloud team.
This update splits the `BootstrapRegistry` API into `BootstrapRegistry`,
`BootstrapContext` and `ConfigurableBootstrapContext` interfaces and
moves it to the same package as `SpringApplication`.
A new `Bootstrapper` interface has been introduced that can be added
to the `SpringApplication` to customize the `BootstrapRegistry` before
it's used.
Closes gh-23326
Andy Wilkinson
dreis2211
Phillip Webb
Madhura Bhave
Hatef Palizgar
Stephane Nicoll
izeye
Stephane Nicoll
Andy Wilkinson