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
Rename `@ConfigurationPropertiesImport` to
`@ImportAsConfigurationPropertiesBean` and also refine the registrar
so that it can be used with type directly annotated with
`@ConfigurationProperties`.
Closes gh-23172
Update `ValidationBindHandler` so that pushed fields that reference
map keys can be used. This fixes a regression that was introduced in
commit 4483f417 when we switched to a `AbstractBindingResult` that no
longer required public getters/setters.
Closes gh-20350
Add repeatable `@ImportConfigurationPropertiesBean` annotation that can
be used to import types and treat them as `@ConfigurationProperties`
beans. This annotation is specifically designed to support third-party
classes that can't contain any Spring annotations.
Closes gh-23172
As of spring-projects/spring-framework#24878, Spring Framework provides
an `ApplicationStartup` infrastructure that applications can use to
collect and track events during the application startup phase.
This commit adds a new `BufferingApplicationStartup` implementation that
buffer `StartupStep`s and tracks their execution time. Once buffered,
these steps can be pushed to an external metrics system or drained
through a web endpoint, to a file...
Closes gh-22603
Update `OriginTrackedYamlLoader` to remove node limits and recursive
parsing restrictions. SnakeYAML 1.26 introduced these options in order
to protect against the "billion laugh attacks" but since we consider
`application.yml` files to be trusted, we don't need these restrictions.
Fixes gh-23096
Extend `initializeSystem` to search the exception stack for a
FileNotFoundException before reporting the error. This allows
us to provide a similar stack trace to the one that used to be
thrown when we had the `ResourceUtils.getURL` check.
See gh-22946
Remove `ResourceUtils.getURL` checking from `LoggingApplicationListener`
so that logging systems can implement custom location support.
Prior to this commit, we checked in the listener if the specified config
location could be opened as a URL. This unfortunately prevents Log4J
extensions such as `log4j-spring-cloud-config-client` from implementing
configurable SSL and credentials support.
See gh-22946
Allow `ConfigDataLocationResolvers` to access `Origin` information for
locations so that they can be used as a parent origin of loaded items.
The `ResourceConfigData...` classes have been reworked so that loaded
`PropertySources` include the parent origin.
See gh-23018
Update the `Origin` interface to include a default `getParent()` method
which can be used to get the parent origin. The `TextResourceOrigin`
has been updated to implement the method against the source `Resource`.
A new `OriginTrackedResource` implementation allows any `Resource` to
be decorated and carry an optional `Origin`.
Ultimately this will allow us to include parent `Origin` information
on properties loaded via a `PropertySourceLoader` without needing any
changes to that interface.
See gh-23018
Update `DefaultBindConstructorProvider` so that binding to objects with
multiple constructors is allowed, as long as there is only one
non-public candidate.
Closes gh-23117
Support a `spring.config.all-locations-optional` property which can be
set to `true` if all config data locations should be considered
optional.
Closes gh-23097
Update config data processing code so that import locations are
mandatory by default. Any import request will now throw a
`ConfigDataLocationNotFoundException` if the specified import
location cannot be found. For optional imports, the user can
use the `optional:` prefix to indicate that the application should
continue to start, even if the location does not exist.
Closes gh-23032
Allow `${..}` property placeholders to be used in `spring.config.import`
properties. Prior to this commit, placeholders were not resolved when
binding the `ConfigDataProperty` instance. Furthermore, binding happened
too early for all placeholders to be resolved correctly. The
`ConfigDataEnvironmentContributor` class now has two states for imported
contributors, `UNBOUND_IMPORT` has the initial unbound state and is
eventually replaced with a `BOUND_IMPORT`.
Closes gh-23020
Expose the `BootstrapRegisty` to both `ConfigDataLocationResolver` and
`ConfigDataLoader` implementations. The registry is exposed via the
context interfaces and may be used to reuse instances that are expensive
to create. It may also be used to ultimately register beans with the
`ApplicationContext`.
Closes gh-22956
Add a simple `BootstrapRegistry` that can be used to store and share
object instances across `EnvironmentPostProcessors`. The registry
can be injected into the constructor of any `EnvironmentPostProcessor`.
Registrations can also perform additional actions when the
`ApplicationContext` has been prepared. For example, they could register
the the bootstrap instances as beans so that they become available to
the application.
See gh-22956
Update `SpringApplicationRunListeners` so that the step action
is optional and does not need to call `end()`.
This commit also introduces a test for the failure case showing
that there is a missed call to end with the initial solution.
See gh-22845
Prior to this commit, DebugAgentEnvironmentPostProcessor throws a
RuntimeException with a generic error message if its initialization
fails. The causing exception is discarded, which makes error analysis
unnecessarily difficult.
This commit attaches the cause to the newly thrown RuntimeException.
See gh-22777
Prior to this commit, the HTTP/2 server auto-configuration for Jetty
would require Conscrypt as a hard dependency.
This commit updates the auto-configuration for more flexibility and now
allows the following deployments:
* JDK9+ with the JDK ALPN implementation
* JDK8u252+ with the backported ALPN implementation
* Conscrypt with no JDK requirement
The auto-configuration now improves detection and guides developers in
case there is a missing `jetty-alpn-*-server` dependency.
The reference docs in the HOWTO section has been updated accordingly.
Closes gh-22188
Phillip Webb
Stephane Nicoll
Andy Wilkinson
Brian Clozel
cbono
Eddú Meléndez
Ralph Goers
Johnny Lim
spencergibb
dreis2211
Scott Frederick
Lopfest
Madhura Bhave
Marten Deinum
davidbilge