Added handler argument to the signature of
AsyncHandlerInterceptor.afterConcurrentHandlingStarted(..).

Renamed AsyncWebUtils to WebAsyncUtils.

# By Arjen Poutsma
* SPR-9768:
  Preserve comments when using JibxMarshaller

Prior to this commit, JibxMarshaller used a SAX ContentHandler to
marshal to StAX XMLEventWriters, which inadvertently resulted in the
deletion of XML comments.

After this commit, JibxMarshaller adapts the XMLEventWriter into an
XMLStreamWriter and comments are preserved.

Issue: SPR-9768

Avoid order-dependent test method failures on JDK7

Issue: SPR-9789

This commit ensures that the 'Created-By:' attribute [1] is added to
each jar's META-INF/MANIFEST.MF in order to identify clearly the vendor
and version of Java used during the build process.

[1]: http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html

Prior to this change, @ComponentScan required the declaration of
exactly one of the #value, #basePackage or #basePackageClasses
attributes in order to determine which package(s) to scan.

This commit introduces support for base package inference, relaxing the
above requirement and falling back to scanning the package in which the
@ComponentScan-annotated class is declared.

Issue: SPR-9586

Float parameter handling appears to be marginally more expensive under
JDK7, with the testGetFloatParameterWithDefaultValueHandlingIsFastEnough
test clocking in anywhere from 250 to 315 ms. This violates the current
test threshold of 250 ms, so this commit ups the timeout value to 350 ms
with the assumption that this is indeed a marginal and therefore overall
negligible performance degradation.

# By Oliver Gierke
* SPR-9781:
  Work around JDK7 String#substring performance regression

String#substring has become significantly slower as of JDK 1.7.0_06 [1],
such that there are performance degradations by a factor of 100-1000 in
ResourceDatabasePopulator, especially for large SQL files.

This commit works around this problem by minimizing the substring scope
to the least amount possible to prevent unnecessary internal copying of
strings (which seems to cause the issue).

[1]: http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-May/010257.html

Issue: SPR-9781

Class#getDeclaredMembers returns arbitrary results under JDK7. This
results in non-deterministic execution of JUnit test methods, often
revealing unintended dependencies between methods that rely on a
specific order to succeed.

JUnit 4.11 contains support for predictable test ordering [1], but at
the time of this commit, JUnit 4.11 has not yet been released.
Therefore we are testing against a snapshot version [2], which has been
uploaded to repo.springsource.org [3] for easy access. Note that this
artifact may be removed when JUnit 4.11 goes GA.

 - Care has been taken to ensure that spring-test's compile-time
   dependency on JUnit remains at 4.10. This means that the spring-test
   pom.xml will continue to have an optional <dependency> on JUnit
   4.10, instead of the 4.11 snapshot.

 - For reasons not fully understood, the upgrade to the 4.11 snapshot
   of junit-dep caused NoSuchMethodErrors around certain Hamcrest
   types, particularly CoreMatchers and Matchers. import statements
   have been updated accordingly throughout affected test cases.

 - Runtime errors also occurred around uses of JUnit @Rule and
   ExpectedException. These have been reverted to use simpler
   mechanisms like @test(expected) in the meantime.

 - Some test methods with order-based dependencies on one another have
   been renamed in order to fall in line with JUnit 4.11's new method
   ordering (as opposed to actually fixing the inter-test
   dependencies). In other areas, the fix was as simple as adding a
   tearDown method and cleaning up state.

 - For no apparent reason, the timeout in AspectJAutoProxyCreatorTests'
   testAspectsAndAdvisorNotAppliedToPrototypeIsFastEnough method begins
   to be exceeded. Prior to this commit the timeout value was 3000 ms;
   on the CI server under Linux/JDK6 and JDK7, the test begins taking
   anywhere from 3500-5500 ms with this commit. It is presumed that
   this is an incidental artifact of the upgrade to JUnit 4.11. In any
   case, there are no changes to src/main in this commit, so this
   should not actually represent a performance risk for Spring
   Framework users. The timeout has been increased to 6000 ms to
   accommodate this situation.

[1]: https://github.com/KentBeck/junit/pull/293
[2]: https://github.com/downloads/KentBeck/junit/junit-dep-4.11-SNAPSHOT-20120805-1225.jar
[3]: https://repo.springsource.org/simple/ext-release-local/junit/junit-dep/4.11.20120805.1225

Issue: SPR-9783

 - Allow reset of GlobalAdvisorAdapterRegistry

   Provide a reset() method allowing the GlobalAdvisorAdapterRegistry
   instance to be replaced with a fresh instance. This method has
   primarily been added to allow unit tests to leave the registry
   in a known state.

 - Protect against the fact that calls to configuration class methods
   my occur in a random order.

Issue: SPR-9779

- Increase max heap size in gradle wrapper.
- Use MockProperties implementation to protect against security
  exceptions.
- Replace windows CRLF with LF in various tests.
- Increase Thread.sleep times to account for lack of precision on
  Windows.

Issue: SPR-9717

Update PortletRequestUtilsTests to use Assert#assertThat and Hamcrest's
Matchers#lessThan in order to output more useful messages when tests
fail.

Errors when parsing the request content-type, in order to find out if
the request has form content, are translated to false.

Issue: SPR-9769

DefaultHandlerExceptionResolver and ResponseEntityExceptionHandler now
both set the "javax.servlet.error.exception" request attribute to the
raised exception, allowing custom error pages configured via web.xml.

Issue: SPR-9653

Issue: SPR-9243

AntPathMatcher now caches AntPathStringMatcher instances by pattern
thus avoiding java.util.regex.Pattern recompilation.

Issue: SPR-9749

While HandlerMethod instances are cached for lookup purposes, a new
ServletInvocableHandlerMethod instance has to be created prior to each
invocation since handlers may have non-singleton scope semantics.

This change reduces the overhead of creating per request instances
by using a logger with a fixed name rather than relying on getClass()
and also by copying introspected method parameters from the cached
HandlerMethod instance.

Issue: SPR-9747, SPR-9748

Issue: SPR-9243

Issue: SPR-9652

Issue: SPR-9670

Issue: SPR-9670

Issue: SPR-9770

Issue: SPR-9741

Issue: SPR-9243

Issue: SPR-9754

This commit refactors the BeanInfoFactory so that:

 - supports() and getBeanInfo() are folded into one, so that getBeanInfo()
    returns null if a given class is not supported.
 - CachedIntrospectionResults now uses SpringFactoriesLoader

 - updated the link to the "indexed properties" section of the JavaBeans
   tutorial

Prior to this change, CachedIntrospectionResults delegated to
ExtendedBeanInfo by default in order to inspect JavaBean
PropertyDescriptor information for bean classes.

Originally introduced with SPR-8079, ExtendedBeanInfo was designed to
go beyond the capabilities of the default JavaBeans Introspector in
order to support non-void returning setter methods, principally to
support use of builder-style APIs within Spring XML. This is a complex
affair, and the non-trivial logic in ExtendedBeanInfo has led to various
bugs including regressions for bean classes that do not declare
non-void returning setters.

This commit takes advantage of the new BeanInfoFactory mechanism
introduced in SPR-9677 to take ExtendedBeanInfo out of the default code
path for CachedIntrospectionResults. Now, the new
ExtendedBeanInfoFactory class will be detected and instantiated (per its
entry in the META-INF/spring.beanInfoFactories properties file shipped
with the spring-beans jar). ExtendedBeanInfoFactory#supports is invoked
for all bean classes in order to determine whether they are candidates
for ExtendedBeanInfo introspection, i.e. whether they declare non-void
returning setter methods.

If a class does not declare any such non-standard setter methods (the
99% case), then CachedIntrospectionResults will fall back to the
default JavaBeans Introspector. While efforts have been made to fix any
bugs with ExtendedBeanInfo, this change means that EBI will not pose
any future risk for bean classes that do not declare non-standard
setter methods, and also means greater efficiency in general.

Issue: SPR-9723, SPR-9677, SPR-8079

 - Ensure that ExtendedBeanInfoTests succeeds when building under JDK 7

 - Improve handling of read and write method registration where
   generic interfaces are involved, per SPR-9453

 - Add repro test for SPR-9702, in which EBI fails to register
   an indexed read method under certain circumstances

Issue: SPR-9702, SPR-9414, SPR-9453