While still present and marked as deprecated, the getPassword()
method on UCP's PoolDataSource has been implemented to throw a
NoSuchMethodError making it useless for our purposes.
This commit updates DataSourceBuilder to avoid using the getter. This
means that a password must now be provided when trying to derive a
new DataSource from an existing PoolDataSource.
Closes gh-28127
Add `MutuallyExclusiveConfigurationPropertiesException` and a related
failure analyzer so that a nice message can be displayed if more than
one mutually exclusive property is defined.
Closes gh-28121
Co-authored-by: Phillip Webb <pwebb@vmware.com>
Previously, the detector for AbstractDataSourceInitializers used the
default detector order. This resulted in the initializers detected
initializers running before Flyway. Constrastingly, the detector for
DataSourceScriptDatabaseInitializers uses a custom order so its
detected initializers would run after Flyway.
This commit aligns the order of the detector for
AbstractDataSourceInitializers with the order of the detector for
DataSourceScriptDatabaseInitializers. This ensures that script-based
initialization runs in the same order with respect to Flyway,
irrespective of which initializer implementation is driving it.
Fixes gh-28079
Previously, SpringApplicationShutdownHook would always register a
shutdown hook, even if SpringApplication was configured not to
use a shutdown hook, such as in a war deployment. This could
result in a memory leak when the war was undeployed. The shutdown
hook registered by SpringApplicationShutdownHook would remain
registered, pinning the web application's class loader in memory.
This commit updates SpringApplicationShutdownHook so that it
registers a shutdown hook with the JVM lazily, upon registeration
of the first application context.
Fixes gh-27987
This commit reworks the configuration properties registrar to use
RootBeanDefinition and a standard attribute rather than relying on
a package private sub-class. This allows other components to inspect
the metadata if necessary.
Closes gh-27821
Add `CustomNumberEditor` and `CustomBooleanEditor` to the editor
exclusions sine the regular `ConversionService` should be able to
handle them.
Closes gh-27829
Update `TypeConverterConverter` do that a new `SimpleTypeConverter` is
obtained for each `convert` operation. Prior to this commit the same
`SimpleTypeConverter` could be accessed concurrently from multiple
threads which is not allowed.
Fixes gh-27829
Some of the Jetty graceful shutdown tests were flaky due to the way
in which Jetty behaves when it is stopped.
Stopping the Jetty web server interrupts the thread that's handling
the active request. This initiates a race between the request-handling
thread which will decrement the number of active requests and the
main thread which expects an active request to cause the shutdown
result to be REQUESTS_ACTIVE. The test passes when the main thread
wins and fails as a request is active which it's checked. When the
request-handling thread wins the test fails as the count of active
requests has been deprecated before it is checked.
The blocking servlet that's used to stall a request and keep it
active needs to be updated to ignore the thread being interrupted
and continue waiting. This will ensure that a request remains active
until the main thread has checked the active request count and
determine the result of the shutdown.
Closes gh-27464
Previously, database initializers were detected and were configured
with dependencies based on their detection order. For example, if
detectors a, b, and c detected initializers a1, b1, b2, and c1,
c1 would depend on b2, b2 on b1, and b1 on a1:
------ ------ ------ ------
| c1 | --> | b2 | --> | b1 | --> | a1 |
------ ------ ------ ------
This could cause a dependency cycle in certain situations, for
example because the user had already configured b1 to depend on b2.
This commit reduces the risk of a cycle being created by batching
the initializers by their detector, with dependencies being
configured between each batch rather than between every initializer.
In the example above, this results in c1 depending on b1 and b2,
and b1 and b2 depending on a1:
------
------ | b1 | ------
| c1 | --> | | --> | a1 |
------ | b2 | ------
------
As b1 and b2 were detected by the same detector, no dependency
between those initializers is defined.
Closes gh-27131
Previously, the presence of a file with the same name
as an optional wildcard location would cause a failure. With
this change the pattern is resolved only if the resource is a
directory.
Additionally, if an optional wildcard search location that was a file
would also fail with an exception. This commit fixes that so that those
locations are not resolved.
Fixes gh-27120
Fixes gh-27209
Previously, SpringApplicationShutdownHook would call close() on any
registered application context even if it wasn't active as it had
already been closed. This could lead to deadlock if the context was
closed and System.exit was called during application context refresh.
This commit updates SpringApplicationShutdownHook so that it only
calls close() on active contexts. This prevents deadlock as it avoids
trying to sychronize on the context's startupShutdownMonitor on
the shutdown hook thread while it's still held on the main thread
which called System.exit and is waiting for all of the shutdown hooks
to complete.
Fixes gh-27049
Update `Instantiator` so that it can accept a `ClassLoader` when
creating instances and rework `EnvironmentPostProcessorsFactory` to
use the new methods.
Prior to this commit we would use the `ClassLoader` to get the class
names from `SpringFactories` but not when actually creating the
instances.
Fixes gh-27043
Previously, Log4j2's own shutdown hook was only disabled when Log4j2
detected javax.servlet.Servlet on the classpath and, therefore,
determined that it was running in a web application. In an application
without Servlet on the classpath, this could lead to both Log4j2's shut
down hook and and logging system's shutdown handler both stopping
Log4j2. This could result in a failure as the second attempt at stopping
would result in reinitialization which would fail as the JVM is already
shutting down.
This commit introduces a new Log4j2 PropertySource implementation,
registered via META-INF/services, that sets the
log4j.shutdownHookEnabled property to false. This will ensure that
Log4j2's own shutdown hook is disabled by default whenever Spring Boot
is on the classpath and not just in Servlet-based web applications.
Fixes gh-26953