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
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
Previously, when a user had declared a custom MultipartResolver bean
that is a CommonsMultipartResolver, part resolution would fail. The
failure was occurring as the servlet container was consuming the parts
before CommonsMultipartResolver had a chance to read them. This was
happening because a MultipartConfigElement was being auto-configured.
This commit updates the multipart auto-configuration so that a
MultipartConfigElement is not auto-configured when there is a
CommonsMultipartResolver bean in the context.
Closes gh-7735
This commit replaces the use of a GET method by a DELETE method for
testing that the HiddenHttpMethodFilter is ordered before the security
filter. With SPR-16836 changes, only PUT DELETE and PATCH are now
allowed.
This commit separates the auto-configuration of JavaMailSender in two
distinct configuration: one based on existing Session available on JNDI
and the other one based on properties configuration.
This clarifies the auto-configuration report and the fact that the JNDI
variant overrides any Session-related properties that would have been
set in the environment
Closes gh-13026
Update `ServerProperties` to also call `setHttpOnly` on the
`TomcatContext`. It appears that this is required in addition to
using the `ServletContextInitializer` to setup `SessionCookieConfig`.
Closes gh-12580
This commit restructures the Cache auto-configuration to avoid an early
init on CacheManager (and potentially all its infrastructure). Rather
than adding a dependency on the validator bean, this commit relies on
the fact CacheAspectSupport checks if a CacheManager is available in the
afterSingletonsInstantiated callback. In this case, a simple bean with
a postconstruct callback is enough.
Closes gh-13038
Spring Buildmaster
Andy Wilkinson
Madhura Bhave
Stephane Nicoll
Phillip Webb
Johnny Lim
Mandap
Brian Clozel
Martin Theiss
Zoltan Reegn