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
Effectively revert commit 0da0d2d46 so that the `resolveProfileSpecific`
method of `ConfigDataLocationResolver` is again called when resolving
imports declared in a profile-specific file.
Fixes gh-26960
This commit modifies the output of BeanNotOfRequiredTypeFailureAnalyzer
to include type information for both the actual and the required types
and to remove ambiguity.
Fixes gh-26821
Add `SpringApplicationShutdownHook` to manage orderly application
shutdown, specifically around the `LoggingSystem`. `SpringApplication`
now offers a `getShutdownHandlers()` method that can be used to add
handlers that are guaranteed to only run after the `ApplicationContext`
has been closed and is inactive.
Fixes gh-26660
Change the order of `DataSourceScriptDatabaseInitializerDetector` so
that it always runs last. This update allows script initialization to
be combined with a high-level migration tool such as Flyway.
Closes gh-26692
Update `DatabaseInitializationDependencyConfigurer` so that depends-on
ordering is applied based on the `DatabaseInitializerDetector` order.
Prior to this commit, if multiple DatabaseInitializer beans were
detected the order in which they were initialized was not defined.
See gh-26692
Update `ConfigurationPropertySourcesPropertyResolver` so that calls to
the `DefaultResolver` do not attempt conversion.
Prior to this commit, the delegate resolver was accidentally called
with the target type which could cause a `ConversionFailedException`
to be thrown. We should have always used `Object.class` and let the
`convertValueIfNecessary` method perform conversion.
Fixes gh-26732
Allow groups to be used with standard locations so that order of
profile-specific files is consistent.
Prior to this commit, the default search locations considered for
application properties/yaml files was the following:
optional:classpath:/
optional:classpath:/config/
optional:file:./
optional:file:./config/
optional:file:./config/*/
Each of these locations was independent which could cause confusion
if certain combinations were used. For example, if profile-specific
files were added to `classpath:/` and `classpath:/config/` then the
latter would always override the former regardless of the profile
ordering.
This commit updates `StandardConfigDataLocationResolver` so that a
group of locations can be specified for each item. This allows us to
define the following set of search locations which provide more logical
ordering for profile-specific files
optional:classpath:/;optional:classpath:/config/
optional:file:./;optional:file:./config/;optional:file:./config/*/
Closes gh-26593
Update the `ConfigDataEnvironment` so that the `resolveProfileSpecific`
method of `ConfigDataLocationResolver` is no longer called when
resolving imports declared in a profile-specific file.
Fixes gh-26753
Update `StandardConfigDataLocationResolver` so that profile-specific
imports can only be used when there is no parent import.
Prior to this commit, given the following application.properties file:
spring.profiles.active=p1,p2
spring.config.import=other.properties
We would attempt to import `other.properties`, `other-p1.properties`
and `other-p2.properties`. This seems quite confusing and when we really
only need to support profile-specific properties for the initial root
set of locations.
Fixes gh-26752
This commit aligns int and long so that a random number is generated
by delegating to ints/longs in the JDK's Random API. In the case of a
single bound value, it needs to be greater than 0 because 0 is used as
the lower bound.
Fixes gh-26628
Previously, LoggingSystem#get would chose Logback by the sole presence
of a class in logback-core, with the assumption that logback-classic is
also on the classpath. An app that only had the former would therefore
fail.
This commit updates the condition to check for a class in
logback-classic instead.
Closes gh-26711
Fix `DataSourceBuilder` so that the type used to access `deriveFrom`
properties is based on the actual instance type rather than the
user-defined type which could have been changed.
Fixes gh-26644
Update `DataSourceBuilder` so that the `driverClassName` may be optional
and silently ignored if it set but the underlying type does not have
a getter/setter.
This restores Spring Boot 2.4 behavior.
Fixes gh-26631
Co-authored-by: Phillip Webb <pwebb@vmware.com>
Update `DataSourceBuilder` so that setters are not longer called for
`null` values. This restores Spring Boot 2.4 behavior.
Fixes gh-26633
Co-authored-by: Phillip Webb <pwebb@vmware.com>
Update `DataSourceBuilder` so that the url property attempts both
`getUrl()` / `setUrl(...)` and `getURL()`/`setURL(...)`.
Fixes gh-26647
Co-authored-by: Phillip Webb <pwebb@vmware.com>
Update `StandardConfigDataLocationResolver` so that directory resources
are only required when the location is not optional.
Closes gh-26627
Co-authored-by: Phillip Webb <pwebb@vmware.com>
Update `ConfigData` so that it signal if is considered optional. This
update allows `ConfigDataLocationResolvers` to return results that
behave in the same way as `optional:` prefixed locations without the
user themselves needing to prefix the location string.
Closes gh-25894
Update `StandardConfigDataLocationResolver` to deal with patterns when
resolving empty directories. This update also fixes the handling of
mandatory pattern locations which would previously throw an exception.
The error message returned when a location with a pattern does not
contain any subdirectories has also been improved.
Fixes gh-26468
Fixes gh-26577
Fixes gh-26415
Update `Profiles` so that any profiles set programmatically on the
`Environment` are merged with `spring.profiles.active` properties.
Fixes gh-26151
Co-authored-by: Phillip Webb <pwebb@vmware.com>
Previously, @ConfigurationProperties was not annotated with @Indexed.
This meant that @ConfigurationPropertiesScan would not be able to
find them when the underlying
ClassPathScanningCandidateComponentProvider is using a
CandidateComponentsIndex.
This commit annotated @ConfigurationProperties with @Indexed so that
they can be found by index-based scanning.
Fixes gh-26459
Update `BufferingApplicationStartup` to use thread safe data structures.
Prior to this commit, it was possible for calls from different threads
(for example due to request scope beans) to cause a
NoSuchElementException to be thrown.
Closes gh-25792
Previously, classes involved in config loading used a variety of
potentially different class loaders when calling SpringFactoriesLoader.
Some classes would use their own class loader and others would use null
which results in SpringFactoriesLoader's class loader being used.
This commit updates the config loading classes to consistently use the
resource loader's class loader.
Fixes gh-26126
Additional profiles were being processed after config file processing
when legacy processing was used.
This commit also restores the order in which additional profiles are added
when legacy processing is used.
Active profiles take precedence over additional profiles.
See gh-25817
Additional profiles were being processed after config file processing
when legacy processing was used.
This commit also restores the order in which additional profiles are added
when legacy processing is used.
Active profiles take precedence over additional profiles.
See gh-25817
Update `ConfigDataEnvironment.checkMandatoryLocations` to use the
actual locations that were imported, including those that were skipped
because the related `ConfigDataResource` had already been imported by a
different location.
Prior to this commit, any location that was skipped because it had
already been imported would throw a `ConfigDataNotFoundException`.
Closes gh-26147
Co-authored-by: Scott Frederick <sfrederick@vmware.com>
Co-authored-by: Madhura Bhave <mbhave@vmware.com>
Update `StandardConfigDataLoader` to mark profile specific files with
`Option.PROFILE` so that they are added in the correct order. This is
a variation of the same issue described in commit 5774ea3f0c.
Closes gh-26400
Co-authored-by: Scott Frederick <sfrederick@vmware.com>
Co-authored-by: Madhura Bhave <mbhave@vmware.com>
This commit updates config data property binding to ignore empty
elements in `spring.config.location` and `spring.config.import`
property values when a value is a comma-delimited string
representing a collection.
Fixes gh-26342
Previously, users of the components.index could not use the index in
scenario where Spring Boot needs to locate the SpringBootConfiguration
to use to bootstrap the test context, as AnnotatedClassFinder scans
the classpath for that stereotype specifically and that requires a
dedicated entry for it.
This commit makes sure that a SpringBootConfiguration-annotated type has
a dedicated entry in the components index.
Closes gh-26308
Update `Log4J2LoggingSystem` so that call to `setLevel` with a `null`
level with remove the logger if it was previously configured by a
`LoggingSystem` call.
To track which loggers have been configured by us, and which have been
configure directly by the user, a custom `LoggerConfig` subclass is
used. We'll only remove `LevelSetLoggerConfig` classes, for any others
we'll call `setLevel(null)` on the config.
Prior to this commit, it was impossible to set then reset a logger
level using the actuator endpoint. This is because Log4J doesn't provide
a way to get the actual configured level. If the `setLevel(null)` has
been applied, then `getLevel()` will return the value of the parent
logger or a default value of `ERROR`.
Fixes gh-24298
Add a `StandardConfigDataResource.getProfile()` method so that it's
possible to tell the profile used when reading a profile specific
resource.
Fixes gh-25940
Update `BindConverter` so that multiple `ConverterServices` can be
specified when binding. This change allows `ConversionServiceDeducer`
to add both the `BeanFactory` conversion service as well as a
custom `ApplicationConversionService` when beans annotated with
`@ConfigurationPropertiesBinding` are found.
Fixes gh-26089
Update `ApplicationConversionService.getSharedInstance()` so that the
instance returned is unmodifiable and converters cannot be added or
removed from it.
Closes gh-26088
Apache HttpClient 5.1 doesn't cope with Jetty 10 sending
SETTINGS_ENABLE_CONNECT_PROTOCOL in the settings frame. It also appears
to be unstable when using Undertow, resulting in a failure and
"UT005032: Listener not making progress on framed channel, closing
channel to prevent infinite loop" being logged on the server-side.
Local experimentation suggests that Jetty's HTTP/2 client is more
robust and that it does not trigger the problem with Undertow. It also
fixes the problem with SETTINGS_ENABLE_CONNECT_PROTOCOL when testing
against Jetty 10 so this commit updates the tests to use Jetty's client.
Closes gh-26040
Update `StandardConfigDataLocationResolver` so that it recognizes
both `/` and `File.separator` suffixes as directories.
Prior to this commit, working with directories on Windows was awkward
since the path separator is `\`. If a directory were specified in the
form `c:\config\`, an exception was raised complaining it did not end
with '/'.
See gh-24490
Add an alternative `PropertySourcesPropertyResolver` that can short
circuit resolution of properties that are already covered by the
`ConfigurationPropertySourcesPropertySource`.
Prior to this commit, calling `getProperty` or `containsProperty` on an
`Environment` that has `ConfigurationPropertySources` attached could
result in two identical calls to the underlying source. The first call
would be via the adapted source, and the second would be direct. Since
we can now plug-in a custom `PropertySourcesPropertyResolver` to the
`Environment`, we can optimize resolution so that calls happen only
once.
Closes gh-17400
Add custom `ApplicationEnvironment`, `ApplicationServletEnvironment`
and `ApplicationReactiveWebEnvironment` subclasses for use with
`SpringApplication`. The subclasses all disable the resolution of
active and default profiles using properties since this is handled
directly by the `ConfigDataEnvironmentPostProcessor`.
Closes gh-24892
See gh-24890
Prior to this commit, the SslServerCustomizer would use a Reactor Netty
API that lets users customize the SSL configuration, but later override
some of the choices with defaults.
This commits moves from the new deprecated Reactor Netty API and instead
uses a new variant that builds the defaults and lets developers override
them if they want to.
Fixes gh-25913
Update the `ConfigData` import support to allow individual property
sources to be imported with a higher precedence than profile specific
imports.
Prior to this commit, imported sources would always have a higher
precedence than the file that imported them, but a lower precedence
than any profile-specific variant of the same file.
For example, given an `application.properties` that imports `myconfig`,
the contributor tree would be as follows:
ROOT
+- `application.properties`
| +- myconfig
+- `application-<profile>.properties`
The precedence would be:
1) `application-<profile>.properties`
2) myconfig
3) `application.properties`
This works well for most situations, but can be confusing if import is
for a profile-specific property source. For example:
ROOT
+- `application.properties`
| +- myconfig
| +- myconfig-<profile>
+- `application-<profile>.properties`
Results in the order precedence of:
1) `application-<profile>.properties`
2) myconfig-<profile>
3) myconfig
4) `application.properties`
This means that whilst `myconfig` overrides `application.properties`,
`myconfig-profile` does not override `application-<profile>.properties`.
For this specific situation, the preferable order would be:
1) myconfig-<profile>
2) `application-<profile>.properties`
3) myconfig
4) `application.properties`
To support this alternative ordering a new `PROFILE_SPECIFIC` config
data option has been added. Additionally, options may now be specified
on a per-source basis by using the `PropertySourceOptions` interface.
Fixes gh-25766
Prior to this commit, some exceptions handled at the controller or
handler function level would:
* not bubble up to the Spring Boot error handling support
* not be tagged as part of the request metrics
This situation is inconsistent because in general, exceptions handled at
the controller level can be considered as expected behavior.
Also, depending on how the exception is handled, the request metrics
might not be tagged with the exception.
This will be reconsidered in gh-23795.
This commit prepares a transition to the new situation. Developers can
now opt-in and set the handled exception as a request attribute. This
well-known attribute will be later read by the metrics support and used
for tagging the request metrics with the exception provided.
This mechanism is automatically used by the error handling support in
Spring Boot.
Closes gh-24028
Andy Wilkinson
Phillip Webb
Stephane Nicoll
dreis2211
Henning Pöttker
Madhura Bhave
marckchr
fengyuanwei
Sviatoslav Hryb
Scott Frederick
izeye
Jamin Hitchcock
weixsun
ChangYong
nguyensach
Roman Zabaluev
Sriram
katielevy1
mederel
Brian Clozel
Alex Belyaev
Julien Dubois