Update `StandardConfigDataLocationResolver` to no longer check if
directories exist for classpath resources. Unfortunately checking for
the parent directory of a `ClassPathResource` isn't always possible
without resorting something similar to the
`PathMatchingResourcePatternResolver` which would add a lot of
complexity to the resolver.
In order to ensure that non-optional locations are always resolved,
the `ConfigDataEnvironment` now checks that all imported locations
have been loaded.
Closes gh-24143
This commit modifies the actuator `EnvironmentEndpoint` to allow
primitive wrapper types to be serialized in the response data
structure.
Fixes gh-24307
This commit reinstanties the isWeBClientPresent() check so that
WebTestClientContextCustomizer is only added if a web client is
available.
See gh-24152
Previously, it was possible for Spring Integration, including its
built-in Micrometer support, to be auto-configured before the
Micrometer auto-configuration had defined the MeterRegistry bean. This
resulted in missing Spring Integration metrics.
Spring Integration is unusual in having its own built-in Micrometer
support that it configures itself. Rather than providing
auto-configuration for Integration's Micrometer support (Which isn't
needed), this commit introduces some auto-configuration that just
affects the ordering of the auto-configuration classes. This ordering
ensures that the MeterRegistry bean has been defined by Spring
Integration is auto-configured. This ensures that the MeterRegistry
bean is known to the BeanFactory when Spring Integration goes looking
for it.
See gh-24095
Web MVC and WebFlux look up by name the Locale(Context)Resolver beans
that they use. Previously, the auto-configured resolvers for MVC and
WebFlux would back off when any bean of the required type was defined,
irrespective of its name. If the name of the user's bean didn't match
the name used by MVC and WebFlux to find the custom resolver, the
custom resolver would be ignored and MVC and WebFlux would use their
defaults. There was no indication of this happening in the condition
evaluation report as all it would show is that the auto-configured
resolver had backed off in favour of the custom resolver. It wouldn't
show anything to explain why the custom resolver had not been used.
This commit updates the auto-configured resolvers to be conditional
on a missing bean of the name required by MVC and WebFlux. If the
user then defines a custom resolver with a different name, the
condition evaluation report will show that the auto-configured
resolver remained as the bean name didn't match.
Fixes gh-24209
Wrapper's isWrapperFor and unwrap methods both take a Class<?> target
but document that the target should be an interface. Prior to this
change, we were calling isWrapperFor with any Class<?> irrespective of
whether or not it was an interface. When using Oracle UCP each call
to isWrapperFor with an interface results in an exception stack trace
being logged.
This commit upates DataSourceUnwrapper to adhere to Wrapper's contract
by only calling isWrapperFor and unwrap with interfaces.
Fixes gh-24154
Update `SpringBootConfigurationFactory` so that it no longer attempts
to get a `LoggingSystem`.
The recent `LoggingSystem` update means makes use of the
`SpringFactoriesLoader` class to load candidate logging systems.
Unfortunately, the `SpringFactoriesLoader` class creates a `Logger`
which (when using Log4J2) causes `SpringBootConfigurationFactory` to
run. Calling `LoggingSystem.get` from `SpringBootConfigurationFactory`
results in a recursive call to `SpringFactoriesLoader` which hasn't
yet been fully initialized. We then see an NPE caused by a `null`
`cache`.
This update removes the call to `LoggingSystem.get` with the assumption
that it would never return `null` anyway.
Fixes gh-24163
Update `ApplicationConversionService` with support for converting
`CharSequence` source types by using existing `String` based converters.
The addition is primarily to allow `ConfigTreePropertySource` values
to be converted correctly.
Closes gh-24171
This commit sets the pull policy to `IF_NOT_PRESENT` where possible
in integration tests for the Maven and Gradle plugins to reduce
the number of times the default Paketo builder and run images are
pulled from Docker Hub.
Fixes gh-24113
Prior to this commit, packaging a Spring Boot application as a container
image with Cloud Native Buildpacks could result in unwanted browser
caching behavior, with "Last-Modified" HTTP response headers pointing to
dates in the far past.
This is due to CNB resetting the last-modified date metadata for static
files (for build reproducibility and container layer caching) and Spring
static resource handling relying on that information when serving static
resources.
This commit introduces a new configuration property
`spring.web.resources.cache.use-last-modified` that can be used to
disable this behavior in Spring if the application is meant to run as a
container image built by CNB.
The default value for this property remains `true` since this remains
the default value in Spring Framework and using that information in
other deployment models is a perfectly valid use case.
Fixes gh-24099
When a Configuration is copied, any before and after resolve actions
that are registered with its ResolvableDependencies are also copied
over. This means that, when a copied configuration is resolved the
resolution actions may be called on a ResolvableDependencies instances
that isn't the one to which they were added.
Previously, the above-described Gradle behaviour would result in
BootJar accessed the ResolvedConfiguration of a Configuration that may
not have yet been resolved. At best this would trigger Configuration
resolution and at worst it would fail. A failure could occur if the
configuration had been copied so that it could be made resolvable.
The afterResolve action would then try to access the
ResolvedConfiguration of the original Configuration. This would trigger
a resolution attempt that fails due to the original configuration being
marked as unresolvable.
This commit updates the afterResolve action in BootJar to check that
the ResolvableDependencies with which it is called matches the
ResolvableDependencies with which it was original registered. Only
when the two match, and therefore the configuration has actually been
resolved, does processing proceed.
Fixes gh-24072
A previous change intended to prevent temporary directories created as
an implementation detail of mounting volumes on kubernetes pods from
being used as a source for property files had a side-effect of also
preventing other types of hidden directories from being recognized. This
commit narrows the criteria for considering a directory as hidden,
using the kubernetes `..` prefix convention instead of the Unix `.`
prefix.
Fixes gh-23983
Previously, when an embedded test database was being auto-configured
any schema username and password specified by the user would result
in a separate embedded test database being created to load the schema.
This then left the actual test database without the schema causing
test failures.
This commit updates the test database auto-configuration to set the
schema username to an empty string in a property source that's added
first to the environment's property sources. This causes any schema
username configured by the user to be ignored, preventing the creation
of a separate database for schema.sql processing.
Fixes gh-19321
Previously, Quartz could be configured with a specific DataSource
using `@QuartzDataSource` but it was not possible to configure a
Quartz-specific transaction manager. This could result in the
different DataSources being used by Quartz itself and Quart'z
DataSourceTransactionManager.
This commit introduces a new qualifier, `@QuartzTransactionManager`,
that can be used to avoid the above-described problem. Any
`@QuartzTransactionManager`-annotated bean will be used by the
Quartz auto-configure configuration instead of the application's main
`TransactionManager`. If no such qualified bean is present, the
application's main TransactionManager, if any, will be used as before.
Fixes gh-20184
The `FreeMarkerViewResolver` (and other template-based resolvers) in
Spring Framework avoid using reflection if they know how to
instantiate the view class. This change aligns with them.
See gh-24011
When running on Java 11 (where `@PostConstruct` is no longer part of
the JRE) and without a dependency on jakarta-annotation-api,
`@PostContruct` annotions are silently dropped. This leads to obscure and
hard-to-track down changes in the behaviour of our auto-configuration
as the `@PostConstruct`-annotated methods are not invoked.
To allow users to run on Java 11 without having jakarta-annotation-api
on the classpath, this commit removes use of `@PostConstruct` from main
code. A Checkstyle rule has also been added to prevent its usage in
main code from being reintroduced.
Closes gh-23723