Add BridgeMethodResolver#isJava6VisibilityBridgeMethodPair to
distinguish between (a) bridge methods introduced in Java 6 to
compensate for inheriting public methods from non-public superclasses
and (b) bridge methods that have existed since Java 5 to accommodate
return type covariance and generic parameters.
In the former case, annotations should be looked up from the original
bridged method (SPR-7900). In the latter, the annotation should be
looked up against the bridge method itself (SPR-8660).
As noted in the Javadoc for the new method, see
http://stas-blogspot.blogspot.com/2010/03/java-bridge-methods-explained.html
for a useful description of the various types of bridge methods, as
well as http://bugs.sun.com/view_bug.do?bug_id=6342411, the bug fixed in
Java 6 resulting in the introduction of 'visibility bridge methods'.
Issue: SPR-8660, SPR-7900
Remove all convenience variants of #findAllAnnotationAttributes and
refactor the remaining method to accept a MetadataReaderFactory
instead of creating its own SimpleMetadataReaderFactory internally.
This allows clients to use non-default class loaders as well as
customize the particular MetadataReaderFactory to be used (e.g.
'simple' vs 'caching', etc).
Issue: SPR-8752
Removed formal deprecation warnings for AbstractSingletonFactoryBean and
its TransactionProxyFactoryBean and CacheProxyFactoryBean subclasses.
This is principally because TPFB is still used by Grails and could
conceivably be used to good effect by any third-party framework in a
similar fashion. CPFB is new with 3.1, but similar use is predictable.
Deprecations have been replaced by strong recommendations that users
avoid these types in modern Spring applications and favor the use of
namespaces and annotatinos, such as tx: and @Transactional (around
since Spring 2.x) and cache: and @Cacheable.
Issue: SPR-8680, SPR-8686
In anticipation of 'destroy method inference' feature, introduce
ConfigurationClassUtils#INFER_METHOD and update @Bean#destroyMethod to
reflect its use.
Issue: SPR-8751
Cite original inspiriation by Domain-Driven Design, but make clear the
flexible and general-purpose nature of Spring's stereotype annotations
such as @Repository and @Service.
Also update @Repository Javadoc with more explicit instructions about
switching on exception translation through use of
PersistenceExceptionTranslationPostProcessor, and update PETPP Javadoc
for style as well as concrete examples of 'resource factories' that
implement the PersistenceExceptionTranslator interface
Issue: SPR-8691
Prior to this change, StandardServletEnvironment evaluated a
"jndiPropertySourceEnabled" flag to determine whether or not to add a
JndiPropertySource. Following the changes introduced in SPR-8490, there
is now no reason not to enable a JNDI property source by default. This
change eliminates the support for "jndiPropertySourceEnabled" and adds
a JndiPropertySource automatically.
Issue: SPR-8545, SPR-8490
A <scheduled:task> element declared within a
<beans default-lazy-init="true"> element represents a contradiction in
terms: such a task will never be executed.
For this reason, we now override any inherited lazy-init settings
when parsing <scheduled:task> elements, forcing lazy-init to false
for the underlying ScheduledTaskRegistrar bean.
Thanks to Mike Youngstrom for contributing an initial patch.
Issue: SPR-8498
This change returns the invocation order of
ConfigurationClassPostProcessor#enhanceConfigurationClasses to its
pre-3.1 M2 state. An earlier (and now unnecessary) refactoring in
service of @Feature method processing caused the change that this now
reverts.
Prior to this change, an instance of ConfigurationClassPostProcessor
would throw IllegalStateException if its
postProcessBeanDefinitionRegistry method were called more than once.
This check is important to ensure that @Configuration classes are
not proxied by CGLIB multiple times, and works for most normal use
cases.
However, if the same CCPP instance is used to process multiple
registries/factories/contexts, this check creates a false negative
because it does not distinguish between invocations of
postProcessBeanDefinitionRegistry across different registries.
A use case for this, though admittedly uncommon, would be creating
a CCPP instance and registering it via
ConfigurableApplicationContext#addBeanDefinitionPostProcessor against
several ApplicationContexts. In such a case, the same CCPP instance
will post-process multiple different registry instances, and throw the
above mentioned exception.
With this change, CCPP now performs lightweight tracking of the
registries/beanFactories that it has already processed by recording
the identity hashcodes of these objects. This is only slightly more
complex than the previous boolean-based 'already processed' flags, and
prevents this issue (however rare it may be) from occurring.
Issue: SPR-8527
Chris Beams
Costin Leau
Sam Brannen
Rossen Stoyanchev
Keith Donald
Juergen Hoeller