This commit introduces support for finding annotations on abstract,
bridge, and interface methods in AnnotatedElementUtils.
- Introduced dedicated findAnnotationAttributes() methods in
AnnotatedElementUtils that provide first-class support for
processing methods, class hierarchies, interfaces, bridge methods,
etc.
- Introduced find/get search algorithm dichotomy in
AnnotatedElementUtils which is visible in the public API as well as
in the internal implementation. This was necessary in order to
maintain backwards compatibility with the existing API (even though
it was undocumented).
- Reverted all recent changes made to the "get semantics" search
algorithm in AnnotatedElementUtils in order to ensure backwards
compatibility, and reverted recent changes to
JtaTransactionAnnotationParser and SpringTransactionAnnotationParser
accordingly.
- Documented internal AnnotatedElementUtils.Processor<T> interface.
- Enabled failing tests and introduced
findAnnotationAttributesFromBridgeMethod() test in
AnnotatedElementUtilsTests.
- Refactored ApplicationListenerMethodAdapter.getCondition() and
enabled failing test in TransactionalEventListenerTests.
- AnnotationUtils.isInterfaceWithAnnotatedMethods() is now package
private.
Issue: SPR-12738, SPR-11514, SPR-11598
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
Covers ReflectionUtils.doWithMethods as well as affected annotation post-processors.
Includes an extension of MethodMetadata for the detection of @Bean default methods.
Issue: SPR-12822
Issue: SPR-10919
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
Previously, adding `@EnableAsync` on a blank application would lead to an
info message stating that `ProxyAsyncConfiguration` is not eligible for
getting processed by all BeanPostProcessors. Concretely, this is ok as
such internal configuration is not meant to be a target of such post
processing.
Revisit the condition for non infrastructure bean only. Add the
infrastructure role to a set of internal configuration, including the
`ProxyAsyncConfiguration`.
Issue: SPR-12761
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
Juergen Hoeller
Sam Brannen
Stephane Nicoll
Kazuki Shimizu