This commit turns a lazy injection point for `HttpMessageConverters`
into an `ObjectProvider`-backed injection.
This allows to lazily rely on that bean without creating for it; in some
environments, such proxy creation can lead to issues like SPR-16990.
See gh-13785
Previously, when a bean was overridden and its type changes,
BeanTypeRegistry could be left with a stale view of the bean's type.
This would lead to incorrect bean condition evaluation as conditions
would match or not match based on the bean's old type.
This commit updates the type registry to refresh its view of a bean's
type when its definition changes.
Closes gh-13588
Previously, the initialization of StandardServletEnvironment's
property sources in SpringBootServletInitializer led to debug logging
calls being made before the LoggingSystem had been initialized. As a
result, the system's default configuration was used and, in the case
of Logback at least, the debug logging was output to System.out
in a war deployment.
This commit updates SpringBootServletInitializer to delay the
initialization of StandardServletEnvironment's property sources until
after the LoggingSystem has been initialized, but still in time for
active profiles to be configured via servlet context parameters
(see gh-9972).
Closes gh-13736
This commit makes sure that Flyway/Liquibase migrates the schema if
necessary before a `JdbcTemplate` is made available as an injection
point.
This commit also adds a test that validates simple datasource
initialization (spring.datasource.*) happens before a `JdbcTemplate`
bean can be used.
Closes gh-13155
Previously, when a DispatcherServlet was registered via a
ServletRegistrationBean, the mappings endpoint did not expose any
information about it as it wasn't detected.
This commit fixes the detection of available DispatcherServlets in the
context so that the mappings endpoint include them all.
Closes gh-13186
During processing of a configuration class, the class's complete
hierarchy is processed and during the processing of each class its
member classes are processed. Previously, each pool-specific
inner-class of DataSourceConfiguration extended the abstract outer
class. This meant that when the import from
DataSourceAutoConfiguration.PooledDataSourceConfiguration caused the
first pool-specific inner-class to be processed,
DataSourceConfiguration would be processed as it was the inner-class's
superclass. In turn all of DataSourceConfiguration's member classes
would then be processed. This caused the first import (of
DataSourceConfiguration.Tomcat) to trigger processing of all of the
other pool-specific inner-classes in whatever order they were found
rather than them being processed in the order in which they are
imported by DataSourceAutoConfiguration.PooledDataSourceConfiguration.
Another part of the problem was that none of the pool-specific
inner-classes were conditional on a missing DataSource bean. This
meant that, when multiple pools were on the classpath, each class
after the first would override the previous class's definition of the
DataSource bean.
This commit updates each of the pool-specific inner-classes so that
they no longer extend DataSourceConfiguration. This ensures that
the inner classes are processed in the order defined in the import
on PooledDataSourceConfiguration. Each of the classes has also been
annotated with @ConditionalOnMissingBean(DataSource.class). This
prevents the DataSource bean definition from being overridden and
ensures that the order of precedence for the pool that will be used
is as defined in the import.
Closes gh-13737
Stephane Nicoll
Johnny Lim
dreis2211
Brian Clozel
Madhura Bhave
Andy Wilkinson