Previously, a cache infrastructure with only a CacheResolver would have
worked fine until the JSR-107 API is added to the classpath. When this is
the case, the JCache support kicks in and an exception cache resolver is
all of the sudden required.
The CacheResolver _is_ different as the default implementation does look
different attributes so if a custom CacheResolver is set, it is not
possible to "reuse" it as a fallback exception CacheResolver.
Now, an exception CacheResolver is only required if a JSR-107 annotation
with an "exceptionCacheName" attribute is processed (i.e. the exception
CacheResolver is lazily instantiated if necessary).
The use case of having a CachingConfigurerSupport with only a
CacheResolver was still broken though since the JCache support only looks
for a JCacheConfigurer bean (per the generic type set on
AbstractCachingConfiguration). This has been fixed as well.
Issue: SPR-12850
(cherry picked from commit 314b069)
If a sub-class of Future (such as ListenableFuture) is used as a return
type and an exception is thrown, the AsyncUncaughtExceptionHandler is
called. Now checking for any Future implementation instead of a faulty
strict matching.
Issue: SPR-12797
This commit ensures that @NumberFormat can be used as a
meta-annotation, as was already the case for @DateTimeFormat.
In addition, this commit polishes FormattingConversionServiceTests and
MvcNamespaceTests.
Issue: SPR-12743
(backported from commits df1d90f & c3408d8)
Prior to this commit, the GroovyBeanDefinitionReader claimed (via its
Javadoc) that it fully supported XML configuration files in addition to
its Groovy DSL; however, this was unfortunately inaccurate since XML
validation was disabled by default which led to certain features of XML
configuration not working. For example, it was impossible to define a
<qualifier> in an XML config file without specifying the 'type'
attribute (which has a default value defined in the spring-beans XSD).
This commit fixes this issue by ensuring that bean definitions in XML
resources are loaded with a "standard" XmlBeanDefinitionReader that is
created with default settings (i.e., with XML validation enabled). With
regard to backwards compatibility, bean definitions defined using the
Groovy DSL are still loaded with an XmlBeanDefinitionReader that has
XML validation disabled by default which is necessary for proper
parsing of the Groovy DSL.
Issue: SPR-12769
(cherry picked from commit 7edc7c2c8f)
Previously, one could only set the list of bean names to exclude from
auto-detection and there was no way to add additional bean names.
MBeanExporter now exposes a addExcludedBean method that can be invoked
during the initialization phase to add bean names to ignore.
Issue: SPR-12686
Previously, if a bean has a scoped proxy and is annotated to be exposed
to the JMX domain, both the scoped proxy and the target instance were
exposed in the JMX domain, resulting in a duplicate entries. Worse, if
such bean defines an explicit name, the application wouldn't start
because of a name conflict.
This commit deals explicitely with scoped proxy and make sure to only
expose the relevant bean.
Issue: SPR-12529
Only compute the error message to display when the generated key is
actually null instead of using Assert.notNull as the cache operation
'toString()' method is non trivial and gets computed regardless of the
result.
Issue: SPR-12527
Previously, any @Configuration class was enhanced to namely implement
DisposableBean in order to remove static callbacks that were registered
for that class. This leads to problem if an ApplicationContext is created
and destroyed within the lifecycle on another ApplicationContext in the
same class loader.
It turns out that the destruction callback is no longer necessary as the
interceptors are now stateless: the VM is free to reclaim any of those if
necessary.
Issue: SPR-12445
The removed test testConfigFileParsingErrorWhenNamedBeans() could cause
a groovyc compilation error, for example when using latest IntelliJ IDEA.
Issue: SPR-12435
