Polish ObjectToStringHttpMessageConverter

Issue: SPR-9738
Work around Servlet dependency in content negotiation

Before this change the PathExtensionContentNegotiationStrategy accessed
the ServletContext via request.getServletContext, which is Servlet 3
specific. To work around it, there is now a Servlet-specific sub-class
that accepts a ServletContext as a constructor argument.

The ContentNegotiationManagerFactoryBean is now ServletContextAware and
if it has a ServletContext it creates the Servlet-specific sub-class
of PathExtensionContentNegotiationStrategy.

The ContentNegotiationManagerFactoryBean is now also used in several
places internally -- MVC namespace, MVC Java config, and the
ContentNegotiatingViewResolver -- to reduce duplication.

Issue: SPR-9826
LiveBeansView produces a well-defined (and valid) JSON document now

Issue: SPR-9662
ResourceBundleMessageSource supports "defaultEncoding", "fallbackToSystemLocale", "cacheSeconds"

These features require Java 6 or higher due to their dependency on the ResourceBundle.Control class. To some degree, ResourceBundleMessageSource catches up with ReloadableResourceBundleMessageSource now. However, as noted in the javadoc, there are still severe limitations in the standard ResourceBundle class that justify an ongoing investment in our own ReloadableResourceBundleMessageSource (based on the Spring resource abstraction, with manual parsing of properties files).

Issue: SPR-7392
TransactionInterceptor avoids reflective method search for method identification

As of Spring 3.0.4, we were trying to expose the target method signature as transaction name. Unfortunately, the algorithm called the ClassUtils.getMostSpecificMethod helper method which performs a quite expensive reflective search. As of this commit, we're simply concatenating the target class name with the method name, accepting the use of the concrete target class (which is arguably more meaningful for monitoring anyway) even when the method implementation actually sits on a base class.

Issue: SPR-9802
ClassUtils.getMostSpecificMethod uses Class.getMethod code path in case of a public method

This should be significantly faster than our standard algorithm, for a very common case. Motivated by SPR-9802, even if the fix there uses a different approach, with transaction name determination not calling getMostSpecificMethod at all anymore.

Issue: SPR-9802
Polish MockFilterChain

A reset method now allows it to be invoked more than once each time
storing the request and response with which it was invoked.
Add mock implementations of Http[Input|Output]Message
Sync up MockHttpServletResponse copies in test sources
Polish LiveBeansView Javadoc and suppress warnings
Add Spring MVC Test framework

This commit adds the spring-test-mvc project [1] to the Spring
Framework as part of the spring-test module.

The sources are added as a root-level project called "spring-test-mvc"
instead of under "spring-test" because the new sources need to be
compiled with Servlet 3 while the current "spring-test" sources require
Servlet 2.5 and the Eclipse IDE does not support having different
classpaths for the same project.

The Gradle build produces a single spring-test jar that contains
sources from both "spring-test" and "spring-test-mvc". This merge is
made possible through merge-dist.gradle as follows:

- jar tasks of the "from" project execute tasks of the "to" project
- "to" project is added to the classpath of the "from" project
- "to" project pom is updated with entries from the "from" project

For further details see documentation in merge-dist.gradle.

Special thanks to everyone who contributed to the initial development
of the Spring MVC Test framework:

 Arjen Poutsma <poutsma@mac.com>
 Craig Walls <cwalls@vmware.com>
 Frans Flippo <fransflippo@utopia.orange11.nl>
 Harry Lascelles <harry@firstbanco.com>
 Irfan <mail.urfi@gmail.com>
 Jörg Rathlev <joerg.rathlev@s24.com>
 Keesun Baik <whiteship2000@gmail.com>
 Keesun Baik <whiteship@epril.com>
 Matthew Reid <matthew.reid@nakedwines.com>
 Nils-Helge Garli Hegvik <Nils-Helge.Hegvik@telenor.com>
 Rob Winch <rwinch@vmware.com>
 Scott Frederick <sfrederick@vmware.com>
 Sven Filatov <sven.filatov@gmail.com>
 Thomas Bruyelle <thomas.bruyelle@gmail.com>
 youngm <youngm@gmail.com>

[1]: https://github.com/SpringSource/spring-test-mvc

Issue: SPR-9859, SPR-7951
merge-dist.gradle disables artifactoryPublish

Previously the project that was getting merged from would try to
execute the artifactoryPublish on the build box. This caused issues
since the mavenDescriptor did not exist.

The merge-dist.gradle now disables the artifactoryPublish task if it
exists (it will only exist on the build box).

Issue: SPR-9859, SPR-7951
Recognize wildcards in media types with a suffix

The "includes" and "isCompatibleWith" methods of MediaType take into
account media types with suffices (e.g. application/soap+xml) including
wildcards with suffices (e.g. application/*+xml). However before this
change, the isWildcardSubtype() method returned true only for subtype
"*". Now a media type such as application/*+xml is also recognized as
having a wildcard subtype.

Issue: SPR-9841
Update MediaType's includes method

An additional update (after the last commit) of the "includes" and
"isCompatibleWith" methods of MediaType to accomodate wildcards
in media types with a suffix.

Issue: SPR-9841
Fix issue in AnnotationMethodHandlerExceptionResolver

Caching of resovled exceptions introduced in SPR-7703 also introduced a
side effect whereby if exactly one exception was previously cached, any
other exception would appear as a match to the previously matched
@ExceptionHandler method.

This change ensures use of a fresh map when determining matching
@ExceptionHandler methods while also updating the cache.

Issue: SPR-9209
Support loading WebApplicationContexts in the TCF

Prior to this commit, the Spring TestContext Framework only supported
loading an ApplicationContext in integration tests from either XML or
Java Properties files (since Spring 2.5), and Spring 3.1 introduced
support for loading an ApplicationContext in integration tests from
annotated classes (e.g., @Configuration classes). All of the
ContextLoader implementations used to provide this support load a
GenericApplicationContext. However, a GenericApplicationContext is not
suitable for testing a web application since a web application relies on
an implementation of WebApplicationContext (WAC).

This commit makes it possible to integration test Spring-powered web
applications by adding the following functionality to the Spring
TestContext Framework.

 - Introduced AbstractGenericWebContextLoader and two concrete
   subclasses:
   - XmlWebContextLoader
   - AnnotationConfigWebContextLoader

 - Pulled up prepareContext(context, mergedConfig) from
   AbstractGenericContextLoader into AbstractContextLoader to allow it
   to be shared across web and non-web context loaders.

 - Introduced AnnotationConfigContextLoaderUtils and refactored
   AnnotationConfigContextLoader accordingly. These utils are also used
   by AnnotationConfigWebContextLoader.

 - Introduced a new @WebAppConfiguration annotation to denote that the
   ApplicationContext loaded for a test should be a WAC and to configure
   the base resource path for the root directory of a web application.

 - Introduced WebMergedContextConfiguration which extends
   MergedContextConfiguration with support for a baseResourcePath for
   the root directory of a web application.

 - ContextLoaderUtils.buildMergedContextConfiguration() now builds a
   WebMergedContextConfiguration instead of a standard
   MergedContextConfiguration if @WebAppConfiguration is present on the
   test class.

 - Introduced a configureWebResources() method in
   AbstractGenericWebContextLoader that is responsible for creating a
   MockServletContext with a proper ResourceLoader for the
   resourceBasePath configured in the WebMergedContextConfiguration. The
   resulting mock ServletContext is set in the WAC, and the WAC is
   stored as the Root WAC in the ServletContext.

 - Introduced a WebTestExecutionListener that sets up default thread
   local state via RequestContextHolder before each test method by using
   the MockServletContext already present in the WAC and by creating a
   MockHttpServletRequest, MockHttpServletResponse, and
   ServletWebRequest that is set in the RequestContextHolder. WTEL also
   ensures that the MockHttpServletResponse and ServletWebRequest can be
   injected into the test instance (e.g., via @Autowired) and cleans up
   thread locals after each test method.

 - WebTestExecutionListener is configured as a default
   TestExecutionListener before DependencyInjectionTestExecutionListener

 - Extracted AbstractDelegatingSmartContextLoader from
   DelegatingSmartContextLoader and introduced a new
   WebDelegatingSmartContextLoader.

 - ContextLoaderUtils now selects the default delegating ContextLoader
   class name based on the presence of @WebAppConfiguration on the test
   class.

 - Tests in the spring-test-mvc module no longer use a custom
   ContextLoader to load a WebApplicationContext. Instead, they now
   rely on new core functionality provided in this commit.

Issue: SPR-5243
Merge pull request #160 from sbrannen/SPR-5243

Support loading WebApplicationContexts in the TCF
Update context-based tests in spring-test-mvc

Added WebAppResourceTests
Removed unused config file TestContextTests-context.xml
Moved servlet-context.xml in package that matches the test classes
Avoid further 'type mismatch' errors in ExtendedBeanInfo

This change fixes further cases under JDK 6 in which setting a bridged
(e.g. String-returning) read method can conflict with an existing
corresponding bridge write method that accepts an Object parameter.

This appears to be a implementation difference between JDKs 6 and 7,
where the JDK 6 Introspector adds bridge methods and JDK 7 does not.

The solution here is to consistently null-out any existing write method
before setting the read method. We were doing this elsewhere in
ExtendedBeanInfo already, but these two changes make the approach
consistent throuhout.

Issue: SPR-8806
HttpComponentsHttpInvokerRequestExecutor uses HttpComponents 4.2 to explicitly release connections

Issue: SPR-9833