Issue: SPR-8751

Anywhere the value of a destroy method may be expressed, specifying
the value "(inferred)" now indicates that the container should attempt
to automatically discover a destroy method. This functionality is
currently limited to detecting public, no-arg methods named 'close';
this is particularly useful for commonly used types such as Hibernate
SessionFactory most JDBC DataSource implementations, JMS connection
factories, and so forth.

This special value is captured as the constant
AbstractBeanDefinition#INFER_METHOD, which in turn serves as the default
value of the @Bean#destroyMethod attribute.

For example in the following case

    @Bean
    public BasicDataSource dataSource() { ... }

the container will automatically detect BasicDataSource#close and invoke
it when the enclosing ApplicationContext is closed. This is exactly
equivalent to

    @Bean(destroyMethod="(inferred)")
    public BasicDataSource dataSource() { ... }

A user may override this inference-by-default convention simply by
specifying a different method

    @Bean(destroyMethod="myClose")
    public MyBasicDataSource dataSource() { ... }

or, in the case of a bean that has an otherwise inferrable 'close'
method, but the user wishes to disable handling it entirely, an empty
string may be specified

    @Bean(destroyMethod="")
    public MyBasicDataSource dataSource() { ... }

The special destroy method name "(inferred)" may also be specified in
an XML context, e.g.

    <bean destroy-method="(inferred)">
        or
    <beans default-destroy-method="(inferred)">

Note that "(inferred)" is the default value for @Bean#destroyMethod,
but NOT for the destroy-method and default-destroy-method attributes
in the spring-beans XML schema.

The principal reason for introducing this feature is to avoid forcing
@Configuration class users to type destroyMethod="close" every time a
closeable bean is configured. This kind of boilerplate is easily
forgotten, and this simple convention means the right thing is done
by default, while allowing the user full control over customization or
disablement in special cases.

Issue: SPR-8751

Issue: SPR-8138

Issue: SPR-8138

renamed mapKey/ValueTypeDescriptor methods back to getMapKey/ValueTypeDescriptor (for Spring 3.0.x compatibility)

[SPR-8240] Added new "Mixing XML resources and @Configuration classes" section to the testing chapter.

Use of package private @Bean methods can cause issues if the class
is extended and the sub-class is in a different package. This is 
covered in detail in SPR-8756.

Reproduces the issue described in SPR-8756 in addition to demonstrating
the suggested workaround.

Issue: SPR-8756, SPR-8725

removed Hibernate EntityManager 4.0 dependency since it is not needed for compilation and not for standard runs of the test suite either

use internal Set for TransactionSynchronization objects in order to allow for equals/hashCode based replacement

Corrected Javadoc: handleListenerException() and invokeErrorHandler() log at WARN level, not at ERROR level.

Certain external javadoc links were broken or out of date, namely
Hibernate, Java SE and EE 6, Quartz, and Apache Pluto. All resolve
properly now.

Issue: SPR-8720

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