This change adds support for @Header and @Headers annotated method
arguments to spring-messaging. Also supported are arguments of type
MessageHeaders, and MessageHeaderAccessor (including sub-types of
MessageHeaderAccessort as long as they provide a wrap(Message<?>)
static factory method).

This change also renames @MessageBody to @Payload.

Issue: SPR-10985

Fix HttpInvokerClientInterceptor.convertHttpInvokerAccessException to
return the translated exception rather than throwing it. This brings
the method implementation in line with the Java Doc and the obvious
original intent.

Issue: SPR-10965

* SPR-10501:
  Add Reference to Spring AMQP Remoting in docs

Beginning with 1.2.0, Spring AMQP now supports remoting over AMQP with
a proxy factory bean an invoker service exporter.

Add documentation to the Spring Framework remoting section with a link
to the Spring AMQP documentation.

Issue: SPR-10501

* fix-doc-cache:
  Fix Cache documentation

Fixed malformed code snippets, formatted whitespace and changed invalid
external link.

The MessageConverter interface in spring-messaging is now explicitly
designed to support conversion of the payload of a Message<?> to and
from serialized form based on MIME type message header.
By default, the MessageHeaders.CONTENT_HEADER header is used but a
custom ContentTypeResolver can be configured to customize that.

Currently available are Jackson 2, String, and byte array converters.
A CompositeMessageConverter can be used to configure several
message converters in various places such as a messaging template.

Issue: SPR-10973

Fix ResolvableType.isAssignableFrom to correctly deal with <?> style
generics.

Issue: SPR-10973

Refactor AbstractMessageConverterMethodArgumentResolver and
BridgeMethodResolver to use ResolvableType in preference to deprecated
GenericTypeResolver calls.

Issue: SPR-10980

Refactor GenericCollectionTypeResolver to make use of ResolvableType
for generic resolution.

Issue: SPR-10977

Refactor GenericTypeResolver to make use of ResolvableType
for generic resolution.

Issue: SPR-10978

Add a new ResolvableType Class which encapsulates java.lang.reflect.Type,
providing access to supertypes, interfaces and generic parameters along
with the ability to ultimately resolve to a java.lang.Class.

ResolvableTypes may be obtained from fields, method parameters, method
returns, classes or directly from a java.lang.reflect.Type. Most methods
will themselves return ResolvableTypes, allowing easy navigation.

For example:

	private HashMap<Integer, List<String>> myMap;

	public void example() {
 		ResolvableType t = ResolvableType.forField(
 					getClass().getDeclaredField("myMap"));
 		t.getSuperType(); // AbstractMap<Integer, List<String>>;
 		t.asMap(); // Map<Integer, List<String>>
 		t.getGeneric(0).resolve(); // Integer
 		t.getGeneric(1).resolve(); // List
 		t.getGeneric(1); // List<String>
 		t.resolveGeneric(1, 0); // String
 	}

Issue: SPR-10973

Issue: SPR-10789

Prior to this commit, one could only match exact URLs in redirectedUrl
and forwardedUrl ResultMatchers. When creating a resource with
a REST service, URLs often contain the id the new resource,
like "/resource/12".

This commit updates those ResultMatchers to support both
exact matches and AntPath matches, using new methods.
The former URL then can be tested against "/resource/*" in MVC tests.

Issue: SPR-10789

This change reverts recent commits made to expand the resource handling
mechanism in Spring MVC. The changes will move into a separate branch
and likely into a separate project allowing it to mature and evolve
without being tied to the main framework release schedule.

Issue: SPR-10933, SPR-10310

This reverts commit d4a0e628, reversing
changes made to 8abe9497.

This reverts commit 1ba806b1.

This reverts commit f8e1f06d.

This reverts commit c01f45fa.

Prior to this commit, one could not test for the absence of
a specific HTTP header in a response.
Using header("X-Custom-Header", Matchers.nullValue()) would not
work because it tests for an empty value of an existing header.

This commit adds a doesNotExist method on the
HeaderResultMatcher.

Issue: SPR-10771

Prior to this commit, one could call the setStatus method on
this Mock object and update the response's status,
even though the sendError method had already been called.

According to the HttpServletResponse Javadoc, sendError() methods
commit the response; so the response can't be written after that.

This commit fixes MockHttpServletResponse's behavior; setStatus
methods do not update the status once the response has been
committed.

Issue: SPR-10414

Comprehensive update to the framework's TimeZone handling, including a new TimeZoneAwareLocaleContext and a LocaleContextResolver for Spring MVC

A few noteworthy minor changes: LocaleContext.getLocale() may return null in special cases (not by default), which our own accessing classes are able to handle now. If there is a non-null TimeZone user setting, we're exposing it to all collaborating libraries, in particular to JSTL, Velocity and JasperReports. Our JSR-310 and Joda-Time support falls back to checking the general LocaleContext TimeZone now, adapting it to their time zone types, if no more specific setting has been provided. Our DefaultConversionService has TimeZone<->ZoneId converters registered. And finally, we're using a custom parseTimeZoneString method now that doesn't accept the TimeZone.getTimeZone(String) GMT fallback for an invalid time zone id anymore.

Issue: SPR-1528

At the same time, dropped GlassFish 1/2 support from GlassFishLoadTimeWeaver and redesigned it to be as analogous to TomcatLoadTimeWeaver as possible.

Issue: SPR-10788

Issue: SPR-10950

Prior to this commit, one couldn't configure Jackson's ObjectMapper
with (De)SerializerModifiers or advanced configuration features
using XML configuration.

This commit updates the FactoryBean and adds a setModule method
that will register Modules with the ObjectMapper.

Note that this commit is only about XML configuration, since
this feature was already available with JavaConfig.

Issue: SPR-10429

Prior to this commit, Multipart databinding would only support
MultiPartFile databinding using commons-multipart.

Now the WebRequestDataBinder supports Part and List<Part>
databinding for Servlet 3.0 compliant containers.

Issue: SPR-10591

Previously, there was no generic concept of a message that represents
a heartbeat and the STOMP-specific code used a null STOMP command to
represent a heartbeat.

This commit introduces HEARTBEAT as a new SimpMessageType. The STOMP
support has been updated to create HEARTBEAT messages to represent
heartbeats, and to use the new message type as the mechanism by which
heartbeats are identified.

Prior to this commit, the intervals at which the broker relay's system
session would send heartbeats to the STOMP broker and expect to
receive heartbeats from the STOMP broker were hard-coded at 10
seconds.

This commit makes the intervals configurable, with 10 seconds being
the default value.

Previously, when the broker relay was shut down, the TCP client was
closed and the relay sessions were left to find out about the
shutdown as a result of their TCP connections being closed. This led
to problems where an attempt could be made to use a session that was,
in fact, in the process of being shut down.

This commit updates the broker relay to explicitly close each of its
relay sessions as part of its stop processing.
As part of the broker relay being shut down explicitly close each of
its relay sessions. It does so before closing the TCP client so that
the relay sessions know that they are  disconnected before their TCP
connections are closed.

The broker relay's publishing of availability events has also been
improved. Prior to this commit, availability events were published
based on the availability of any relay session. For example, this
meant that a successfully established client relay session would
result in an event being published indicating that the broker's
available even if the system relay session was yet to be established.
This commit updates the relay so that broker availability events are
only published by the system relay session. This allows application
code the use these events as an accurate indication of the
availability of the broker. Clients that are interested in the
broker's availability can find out through the use of heart beats or
through the receipt of an ERROR frame in response to an attempt to
communnicate with the broker.

Issue: SPR-10893

Issue: SPR-10923