* DavidBiesack-master:
  Minor fix in Javadoc for RequestMapping

Issue: SPR-9483

Issue: SPR-9513

* rstoyanchev/SPR-4984:
  Add splitIndex Javadoc option to the root project

Splits the very large index page with all classes into individual pages
organized by first letter.

Issue: SPR-4984

* SPR-8917:
  Allow parsing of media types with single-quotes

Previously MediaType could only parse double-quoted parameters without
raising an IllegalArgumentException. Now parameters can also be
single-quoted.

Issue: SPR-8917

HttpStatus cannot be created with an unknown status code. If a server
returns a status code that's not in the HttpStatus enum values, an
IllegalArgumentException is raised. Rather than allowing it to
propagate as such, this change ensures the actual exception raised is
a RestClientException.

Issue: SPR-9406

A recent commit made aopalliance optional for spring-aop, while
continuing to require it for spring-tx. On review, this is probably
overly aggressive, and for convenience aopalliance should remain
required for spring-aop. There are use cases for which aopalliance is
indeed optional, but core functionality such as <aop:scoped-proxy>
should never result in a ClassNotFoundException.

This commit returns the aopalliance dependency for spring-aop to
required status, and also explicitly notes the same dependency in other
modules that compile directly against aopalliance types.

Issue: SPR-9501

Issue: SPR-9494

The junit:junit Maven artifact includes a bundled version of hamcrest
core. For projects that depend on later versions of hamcrest this causes
significant issues in terms of dependency management.

The spring-test module now depends on junit:junit-dep, thus allowing
developers to better manage their test dependencies on a more fine
grained level.

Also tidied up dependency issues regarding hamcrest-core and
hamcrest-all across the build.

Issue: SPR-6966

This commit introduces a test suite (Spr8849Tests) that demonstrates
the claims made in SPR-8849.

Specifically, if <jdbc:embedded-database id="xyz" /> is used to create
an embedded HSQL database in an XML configuration file and that
configuration file is imported in different sets of configuration files
that are used to load ApplicationContexts for different integration
tests, the embedded database will be initialized multiple times using
any nested <jdbc:script /> elements. If such a script is used to create
a table, for example, subsequent attempts to initialize the database
named "xyz" will fail since an embedded database named "xyz" already
exists in the JVM.

As a work-around, this test suite uses a SpEL expression to generate a
random string for each embedded database instance:

  id="#{T(java.util.UUID).randomUUID().toString()}"

See the Javadoc in Spr8849Tests for further information.

Issue: SPR-8849

* SPR-9457:
  Use transactional connection during db population

Previously, DatabasePopulatorUtils#execute looked up a Connection from
the given DataSource directly which resulted in the executed statements
not being executed against a transactional connection (if any) which in
turn resulted in the statements executed by the populator potentially
not being rolled back.

Now DataSourceUtils#getConnection is used to transparently take part in
any active transaction and #releaseConnection is used to ensure the
connection is closed if appropriate.

Issue: SPR-9457

* SPR-7938:
  Include response headers in RestTemplate exceptions
  Polish web.client exceptions and related classes

Default HTTP error exceptions thrown from RestTemplate now include
response headers in addition to the response body. In particular, this
enables inspection of the Content-Type header allowing manual
deserialization of the response body without guessing as to the content
type.

 - introduce HttpStatusCodeException#getResponseHeaders
 - add constructor with headers param for HttpStatusCodeException,
   HttpClientErrorException and HttpServerErrorException
 - preserve exsisting constructor signatures
 - mark HttpHeaders as Serializable
 - generate new serialVersionUID where needed

Issue: SPR-7938

The following style updates have been made in anticipation of
substantive changes in subsequent commits:

 - organize imports
 - correct whitespace errors (leading spaces in code, tabs in Javadoc)
 - wrap Javadoc at 90 chars; make imperative ("Return" vs. "Returns")
 - use conventional constructor argument wrapping

A serialVersionUID has also been added to RestClientException and its
ResourceAccessException subclass for consistency with the rest of that
same exception hierarchy.

Issue: SPR-7938

 - Explicitly specify compile-time dependencies on other spring-*
   modules, primarily for accuracy in pom generation and ensuring
   minimal dependencies for users of spring-aspects.

 - Remove use of p: namespace from annotation-cache-aspectj.xml to
   avoid parser-related test failures under Eclipse (likely due to
   classpath differences between Gradle and Eclipse).

The spring-intstrument jar should have a 'Premain-Class:' manifest
entry in order to enable use as a Java agent. This entry was present in
versions 3.1.1 and earlier, but due to build infrastructure changes
starting in 3.2.x this entry was missed. It is now back in place as
expected.

Issue: SPR-9458

Gradle-generated poms thoroughly tested against 3.1.1 versions, with an
eye toward making as many spring-* dependencies optional as possible.

All spring-* modules now declare a Gradle dependency on any other
spring-* module where there is a direct compile-time usage of the
sources in that module. Previously, dependency declarations were
minimal, letting transitive resolution do most of the work. However,
this creates less than ideal poms and is generally not very
informative.

So for example, spring-jdbc uses spring-core, spring-beans and
spring-tx classes directly. Therefore it has the following declarations:

  compile project(":spring-core")
  compile project(":spring-beans")
  compile project(":spring-tx")

spring-core depends on spring-asm, but spring-jdbc does not use
spring-asm classes directly. Therefore spring-jdbc does not declare a
dependency on spring-asm. Transitive resolution is fine in such a case.

As for optional dependencies, it is a matter of degrees what
constitutes optional. A rule of thumb is whether there are legitimate
and likely use cases in which the module can be used without needing
the dependency. spring-jdbc has only one compile-time dependency on
spring-context classes, and that's in JndiDataSourceLookup. It is
certainly reasonable to imagine using spring-jdbc without JNDI,
therefore the spring-context dependency is declared optional as
follows:

  compile(project(":spring-context"), optional) // for JndiDataSourceLookup

Avoid Eclipse classpath conflicts between test versions of @Qualified
and @Autowired living in spring-core and actual versions living in
spring-beans.

In Spring 3.1 the spring-test Maven artifact did not have a required
dependency on spring-core, but there is practically no part of
spring-test that can be used without spring-core. Most test utilities
that are intended to be stand-alone utilities in fact use utility
classes from spring-core (e.g., ReflectionTestUtils). Even some of the
web mocks/stubs use spring-core (e.g., DelegatingServletInputStream).

In addition, the current Gradle build configuration for the spring-test
module is very simplistic -- in that it does not explicitly list any
optional dependencies such as the Servlet and Portlet APIs -- and it
defines a 'compile' dependency on spring-webmvc-portlet.

The resulting Maven dependencies in the generated POM are therefore not
what a typical consumer of the spring-test artifact would reasonably
expect.

To address these issues, the Gradle build configuration for the
spring-test module now explicitly defines the following 'compile'
dependencies:

 - spring-core
 - spring-webmvc, optional
 - spring-webmvc-portlet, optional
 - junit, optional
 - testng, optional
 - servlet-api, optional
 - jsp-api, optional
 - portlet-api, optional
 - activation, provided

The only required dependency is now spring-core; all other dependencies
are 'optional'.

Issue: SPR-8861

EhCacheFactoryBean now applies listeners and enabled/disabled flags to
existing cache regions as well.

Issue: SPR-9392

Issue: SPR-8774

StandardServletMultipartResolver#cleanupMultipart now takes care to
delete only actual file parts for Resin compatibility.

Issue: SPR-9299

ServletContextResource#getFile now falls back to #getRealPath for
non-existent files

Issue: SPR-8461

 - Improve wording & grammar in SmartValidator Javadoc
 - Suppress 'rawtypes' warnings in SpringValidatorAdapter

* SPR-6870:
  Cache by-type lookups in DefaultListableBeanFactory
  Polish

Prior to this change, by-type lookups using DLBF#getBeanNamesForType
required traversal of all bean definitions within the bean factory
in order to inspect their bean class for assignability to the target
type. These operations are comparatively expensive and when there are a
large number of beans registered within the container coupled with a
large number of by-type lookups at runtime, the performance impact can
be severe. The test introduced here demonstrates such a scenario clearly.

This performance problem is likely to manifest in large Spring-based
applications using non-singleton beans, particularly request-scoped
beans that may be created and wired many thousands of times per second.

This commit introduces a simple ConcurrentHashMap-based caching strategy
for by-type lookups; container-wide assignability checks happen only
once on the first by-type lookup and are afterwards cached by type
with the values in the map being an array of all bean names assignable
to that type. This means that at runtime when creating and autowiring
non-singleton beans, the cost of by-type lookups is reduced to that of
ConcurrentHashMap#get.

Issue: SPR-6870

Issue: SPR-6870

Previously (since Spring 3.1.1) RecursiveAnnotationAttributesVisitor
logs at level WARN when ASM parsing encounters an annotation or an (enum
used within an annotation) that cannot be classloaded. This is not
necessarily indicative of an error, e.g. JSR-305 annotations such as
@Nonnull may be used only for static analysis purposes, but because
these annotations have runtime retention, they remain present in the
bytecode. Per section 9.6.1.2 of the JLS, "An annotation that is present
in the binary may or may not be available at run-time via the reflective
libraries of the Java platform."

This commit lowers the log level of these messages from warn to debug,
but leaves at warn level other messages dealing with the ability
reflectively read enum values from within annotations.

Issue: SPR-9233

The following syntax is now supported

  <beans profile="p1,!p2">

  @Profile("p1", "!p2")

indicating that the <beans> element or annotated component should
be processed only if profile 'p1' is active or profile 'p2' is not
active.

Issue: SPR-8728

* SPR-9439:
  Introduce ConfigurableWebEnvironment
  Introduce ConfigurableEnvironment#merge
  Polish

Changes introduced in Spring 3.1 for Environment support inadvertently
established a cyclic dependency between the
org.springframework.web.context and
org.springframework.web.context.support packages, specifically through
web.context.ContextLoader's invocation of
web.context.support.WebApplicationContextUtils#initServletPropertySources.

This commit introduces ConfigurableWebEnvironment to break this cyclic
dependency. All web.context.ConfigurableWebApplicationContext types now
return web.context.ConfigurableWebEnvironment from their #getEnvironment
methods; web.context.support.StandardServletEnvironment now implements
ConfigurableWebEnvironment and makes the call to
web.context.support.WebApplicationContextUtils#initServletPropertySources
within its implementation of #initPropertySources. This means that
web.context.ContextLoader now invokes
web.context.ConfigurableWebEnvironment#initPropertySources instead of
web.context.support.WebApplicationContextUtils#initServletPropertySources
and thus the cycle is broken.

Issue: SPR-9439