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
