Prior to this change, @EnableTransactionManagement (via the
ProxyTransactionManagementConfiguration class) did not properly
register its auto-proxy creator through the usual AopConfigUtils
methods.  It was trying to register the APC as a normal @Bean method,
but this causes issues (SPR-8494) with the logic in
AopConfigUtils#registerOrEscalateApcAsRequired, which expects the APC
bean definition to have a beanClassName property.  When the APC is
registered via a @Bean definition, it is actually a
factoryBean/factoryMethod situation with no directly resolvable
beanClass/beanClassName.

Rather than trying to rework how AopConfigUtils works, a @PostConstruct
method has been added to ProxyTransactionManagementConfiguration to call
the usual AopConfigUtils registration methods.

Issue: SPR-8411, SPR-8494

SessionFactoryBuilderSupport implementations create DisposableBean
proxies for SessionFactory objects created using #buildSessionFactory.

Prior to this change, these proxies create problems when working agaist
SessionFactoryUtils.getDataSource(SessionFactory), because this method
expects the given SessionFactory to implement Hibernate's
SessionFactoryImplementor interface (which the stock SessionFactoryImpl
does).

With this change, the DisposableBean proxies created by SFBuilders
now also implement SessionFactoryImplementor to satisfy this and
probably other such cases.

Issue: SPR-8469

For the particular use case detailed in SPR-8514, with this change we
now attempt to determine the object type of a FactoryBean through its
generic type parameter if possible.

For (a contrived) example:

@Configuration
public MyConfig {
    @Bean
    public FactoryBean<String> fb() {
        return new StringFactoryBean("foo");
    }
}

The implementation will now look at the <String> generic parameter
instead of attempting to instantiate the FactoryBean in order to call
its #getObjectType() method.

This is important in order to avoid the autowiring lifecycle issues
detailed in SPR-8514.  For example, prior to this change, the following
code would fail:

@Configuration
public MyConfig {
    @Autowired Foo foo;

    @Bean
    public FactoryBean<String> fb() {
        Assert.notNull(foo);
        return new StringFactoryBean("foo");
    }
}

The reason for this failure is that in order to perform autowiring,
the container must first determine the object type of all configured
FactoryBeans.  Clearly a chicken-and-egg issue, now fixed by this
change.

And lest this be thought of as an obscure bug, keep in mind the use case
of our own JPA support: in order to configure and return a
LocalContainerEntityManagerFactoryBean from a @Bean method, one will
need access to a DataSource, etc -- resources that are likely to
be @Autowired across @Configuration classes for modularity purposes.

Note that while the examples above feature methods with return
types dealing directly with the FactoryBean interface, of course
the implementation deals with subclasses/subinterfaces of FactoryBean
equally as well.  See ConfigurationWithFactoryBeanAndAutowiringTests
for complete examples.

There is at least a slight risk here, in that the signature of a
FactoryBean-returing @Bean method may advertise a generic type for the
FactoryBean less specific than the actual object returned (or than
advertised by #getObjectType for that matter). This could mean that an
autowiring target may be missed, that we end up with a kind of
autowiring 'false negative' where FactoryBeans are concerned. This is
probably a less common scenario than the need to work with an autowired
field within a FactoryBean-returning @Bean method, and also has a clear
workaround of making the generic return type more specific.

Issue: SPR-8514

Issue: SPR-8514

isCglibProxy* methods in AopUtils are useful in lower-level modules,
i.e. those that cannot depend on .aop.  Therefore copied these methods
to ClassUtils; deprecated the existing ones in AopUtils and now
delegating to the new location; switched all usage of
AopUtils#isCglibProxy* within the framework to use
ClassUtils#isCglibProxy* instead.

Even after applying @Ignore to these tests at the class level, they
still run (and fail) under ant when the jmxremote_optional jar is not
present. See the issues mentioned below for information on how these
tests will be re-enabled.

Issue: SPR-8089, SPR-8093, SPR-8458

removed references to JSR 330  since there is now a dedicated JSR 330 section inside beans-standard-annotations.xml

removed reference to JSR 330's @Named since there is now a dedicated JSR 330 section inside beans-standard-annotations.xml

minor wording change

removed reference to @Provider

JavaMailSenderImpl detects and respects "mail.transport.protocol" property in existing Session (SPR-8501)

Prior to this change, (Context)SingletonBeanFactoryLocator used
BeanFactoryUtils#beanOfType(ListableBeanFactory, Class) to locate the
bean of type BeanFactory.

The more modern approach is to use BeanFactory#getBean(Class), which
removes a dependency on ListableBeanFactory interface while at the same
time opening the implementation up to respecting autowiring exclusions,
primary metadata, etc.

Issue: SPR-8489

For consistency with all other constants representing default
property source names, such as
StandardServletEnvironment#SERVLET_CONTEXT_PROPERTY_SOURCE_NAME and
StandardEnvironment#SYSTEM_ENVIRONMENT_PROPERTY_SOURCE_NAME

Issue: SPR-8482

Prior to this change, JndiPropertySource worked directly against a JNDI
Context instance as its 'source' object.  This works well enough, but is
not nearly as fully-featured as Spring's existing JndiLocatorDelegate.

This change refactors JndiPropertySource from relying on an underlying
Context to relying on an underlying JndiLocatorDelegate.  By default,
the delegate's "resourceRef" property is set to true, meaning that the
implementation will always try to prepand a given name with
"java:comp/env/" before looking up the name, and upon failure will drop
back to the given name sans prefix.

See JndiPropertySource Javadoc for complete details.

Issue: SPR-8490

Move JNDI_PROPERTY_SOURCE_ENABLED_FLAG from JndiPropertySource to
StandardServletEnvironment, as this is the only context in which the
constant makes sense.

Issue: SPR-8490

Users may now work with command line arguments as a source of
properties for use with the PropertySource and Environment APIs.
An implementation based on the jopt library and a "simple"
implementation requiring no external libraries are are provided
out-of-the box.

See Javadoc for CommandLinePropertySource, JOptCommandLinePropertySource
and SimpleCommandLinePropertySource for details.

Issue: SPR-8482

+ add no-op cache implementations suitable for cache declarations w/o a backing store

Issue: SPR-8496

SPR-8447 Provide sufficient contextwherever possible when exceptions are raised in new @mvc classes.