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

SPR-8532 Exclude Tiles transitive deps on 'com.springsource.javax.servlet' from 'com.springsource.org.apache.tiles.jsp' and 'com.springsource.org.apache.tiles.servlet' only.

+ add LTW support for JBoss 7
(renamed existing classes to MC (JBoss 5&6) and introduced Modules (JBoss 7))

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.

SPR-8001 Recognize case when MultipartRequest is null and argument is of type MultipartFile and raise helpful exception.

SPR-8532 Upgrade org.springframework.web.servlet to Servlet 3.0 (as provided dependency) and add support for javax.servlet.Part parameter

[SPR-8387] Fixed logic errors in DelegatingSmartContextLoader.processContextConfiguration() and ContextConfigurationAttributes.hasResources().

[SPR-8387] Fleshing out the implementation of processContextConfiguration() in DelegatingSmartContextLoader.

extended Servlet API mocks for Servlet 3.0 forward compatibility as far as possible; made MockHttpServletResponse compatible with Servlet 3.0 getHeader(s) method returning Strings (SPR-8529); added getHeaderValue(s) method to MockHttpServletResponse for raw value access

call setEnvironment before other awareness methods rather than after; fixed AccessControlContext applicability check

extended Servlet API mocks for Servlet 3.0 forward compatibility as far as possible; made MockHttpServletResponse compatible with Servlet 3.0 getHeader(s) method returning Strings (SPR-8529); added getHeaderValue(s) method to MockHttpServletResponse for raw value access

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

Issue: SPR-8411, SPR-8494

<emphasis role="bold"> blocks do not render properly, probably due to
conflicting CSS used for syntax highlighting. For the moment, any
mentions of bold text (e.g. "see bold text in the snippet below") have
been removed to avoid confusion as reported in SPR-8520.  SPR-8526 has
been created to address the underlying issue of getting bold to work
even with syntax highlighting.

Issue: SPR-8520, SPR-8526

an EntityManagerFactoryBean is only deserializable through a SerializedEntityManagerFactoryBeanReference

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.

To solve this problem, ImportSelector#selectImports has been refactored
to accept an ImportSelector.Context instance. This object contains the
AnnotationMetadata of the importing class as well as the enclosing
BeanDefinitionRegistry to allow for the kind of conditional bean
registration necessary here. In this case, the bean definition that
must be registered conditionally is that of the auto-proxy creator.
It should only be registered if AdviceMode == PROXY, and thus the
ImportSelector is an appropriate place to make this happen.  It must
happen as a BeanDefinition (rather than a @Bean method) for
compatibility with AopConfigUtils, and working with the
BeanDefinitionRegistry API allows for that. This change does mean that
in certain cases like this one, #selectImports has container modifying
side effects. Documentation has been updated to reflect.

Issue: SPR-8411, SPR-8494

@PostConstruct added to ProxyTransactionManagementConfiguration cases
ConcurrentModificationException (as detailed previously in SPR-8397.
Backing out for now until a better solution can be devised.

This reverts commit 235b729514d125aef79fc3fae4bcfb1893642212.

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