This commit deletes methods in RollbackForRequiredEjbTxDaoTestNGTests
that were unnecessarily redeclared. The redeclaration is required for
JUnit's @FixMethodOrder support but not for TestNG's built-in support
for dependent methods.

Issue: SPR-6132

Prior to this commit, all MethodMessageHandlers tests were
implemented in a single class. Since SimpAnnotationMsgHandler
has been refactored with an abstract class, tests also
needed such a refactoring.

This commit creates test fixtures for AbstractMethodMessageHandler.

Issue: SPR-11191

Prior to this commit, it was not clear how to enable the support of matrix
variables in the mvc namespace. As the feature is disabled by default, added
something to highlight the part that explains how to configure it

Issue: SPR-11331

This allows us to avoid early initialization of footprint-heavy ConcurrentHashMaps, and reuses the existing postProcessingLock which will typically be active already when registerExternallyManaged* calls come in from the bean factory's post-processing phase.

Issue: SPR-11343

Introduce EJB-based transactional tests in the TCF

This commit introduces transactional integration tests executing
against both JUnit and TestNG in the TestContext framework (TCF) using
@TransactionAttribute in EJBs instead of Spring’s @Transactional
annotation.

These tests disprove the claims raised in SPR-6132 by demonstrating that
transaction support in the TCF works as expected when a transactional
EJB method that is configured with TransactionAttribute.REQUIRES_NEW is
invoked. Specifically:

 - The transaction managed by the TCF is suspended while such an EJB
   method is invoked.
 - Any work performed within the new transaction for the EJB method is
   committed after the method invocation completes.
 - The transaction managed by the TCF is resumed and subsequently
   either rolled back or committed as necessary based on the
   configuration of @Rollback and @TransactionConfiguration.

The configuration for the JUnit-based tests is straightforward and self
explanatory; however, the configuration for the TestNG tests is less
intuitive.

In order for the TCF to function properly, the developer must ensure
that test methods within a given TestNG test (whether defined locally,
in a superclass, or somewhere else in the suite) are executed in the
proper order. In a stand-alone test class this is straightforward;
however, in a test class hierarchy (or test suite) with dependent
methods, it is necessary to configure TestNG so that all methods within
an individual test are executed in isolation from test methods in other
tests. This can be achieved by configuring a test class to run in its
own uniquely identified suite (e.g., by annotating each concrete
TestNG-based test class with @test(suiteName = "< Some Unique Suite
Name >")).

For example, without specifying a unique suite name for the TestNG
tests introduced in this commit, test methods will be executed in the
following (incorrect) order:

 - CommitForRequiredEjbTxDaoTestNGTests.test1InitialState()
 - CommitForRequiresNewEjbTxDaoTestNGTests.test1InitialState()
 - RollbackForRequiresNewEjbTxDaoTestNGTests.test1InitialState()
 - RollbackForRequiredEjbTxDaoTestNGTests.test1InitialState()
 - CommitForRequiredEjbTxDaoTestNGTests.test2IncrementCount1()

The reason for this ordering is that test2IncrementCount1() depends on
test1InitialState(); however, the intention of the developer is that
the tests for an individual test class are independent of those in
other test classes. So by specifying unique suite names for each test
class, the following (correct) ordering is achieved:

 - RollbackForRequiresNewEjbTxDaoTestNGTests.test1InitialState()
 - RollbackForRequiresNewEjbTxDaoTestNGTests.test2IncrementCount1()
 - RollbackForRequiresNewEjbTxDaoTestNGTests.test3IncrementCount2()
 - CommitForRequiredEjbTxDaoTestNGTests.test1InitialState()
 - CommitForRequiredEjbTxDaoTestNGTests.test2IncrementCount1()
 - CommitForRequiredEjbTxDaoTestNGTests.test3IncrementCount2()
 - RollbackForRequiredEjbTxDaoTestNGTests.test1InitialState()
 - RollbackForRequiredEjbTxDaoTestNGTests.test2IncrementCount1()
 - RollbackForRequiredEjbTxDaoTestNGTests.test3IncrementCount2()
 - CommitForRequiresNewEjbTxDaoTestNGTests.test1InitialState()
 - CommitForRequiresNewEjbTxDaoTestNGTests.test2IncrementCount1()
 - CommitForRequiresNewEjbTxDaoTestNGTests.test3IncrementCount2()

See the JIRA issue for more detailed log output.

Furthermore, @DirtiesContext(classMode = ClassMode.AFTER_CLASS) has
been used in both the JUnit and TestNG tests introduced in this commit
in order to ensure that the in-memory database is reinitialized between
each test class.

Issue: SPR-6132

Prior to this commit, several spring-messaging exceptions
had defined serialVersionUIDs. Those exception aren't
supposed to leave the system via Java serialization; also,
their deserialization is supported only against the same
version of Spring.

Issue: SPR-11339

Issue: SPR-10886
Issue: SPR-7342

Undertow tests fail against OpenJDK 8 build 124 with a BindException.

Update ResolvableType to unwrap Serialization wrapped TypeVariables
before calling the equals method.

This protects against the recent change in OpenJDK 8 (build 124)
which changed the TypeVariableImpl equals method such that it only
matches against other TypeVariableImpl instances.

Issue: SPR-11342

Issue: SPR-11302

Change SerializableTypeWrapper proxies to directly call equals() methods
on the underlying Type, rather than possibly generating more wrappers.

This should help to improve performance, especially as the equals()
method is called many times when the ResolvableType cache is checked.

Issue: SPR-11335

Issue: SPR-11327

The interface is to be implemented in addition to
java.security.Principal when Principal.getName() is not globally unique
enough for use in user destinations.

Issue: SPR-11327

Issue: SPR-11341

Issue: SPR-3983

Note: A default orm.xml file is only being used when not co-located with a persistence.xml file, since we assume it is intended for use with that persistence.xml file only then.

Issue: SPR-11234
Issue: SPR-11260

The ServletTestExecutionListener is now prepended to the set of default
listeners in AbstractJUnit4SpringContextTests and
AbstractTestNGSpringContextTests.

Issue: SPR-11340

Prior to this commit TestNG tests would only be executed by the Gradle
build if they were located in the “testng” package. Tests in subpackages
would therefore be omitted from the build.

This commit ensures that all TestNG classes in the “testng” package and
any of its subpackages are executed in the Gradle build.

Furthermore, this commit ensures that the JUnit-based
FailingBeforeAndAfterMethodsTests test class is executed along with the
other JUnit tests even though it resides under the “testng” package.

Issue: SPR-11338

Issue: SPR-11337

Prior to this commit, it was necessary to override
the HandlerMapping definition to change properties
like useSuffixPatternMatch, useSuffixPatternMatch...
Also, one couldn't set custom pathmatcher/pathhelper
on RequestMappingHandlerMapping via XML configuration.

This commits adds a new "mvc:annotation-driven"
subelement called "mvc:path-matching" for the tag
that allows to configure such properties:
* suffix-pattern
* trailing-slash
* registered-suffixes-only
* path-matcher
* path-helper

Note: this is a new take on this issue, since
96b418cc has been reverted by e2b99c3.

Issue: SPR-10163

This reverts commit 96b418cc,
"Make RequestMappingHandlerMapping xml config easier".

This implementation makes the mvc:annotation namespace less readable,
and future configuration items would add even more to this namespace.

Issue: SPR-10163

Issue: SPR-11129

Allow HttpHeader instances to be returned directly from MVC controller
methods managed by HandlerMethodReturnValueHandler rather than needing
to be wrapped in a ResponseEntity.

Issue: SPR-11129

Upgrade to the latest release of jexcelapi and work-around the
ArrayIndexOutOfBounds test exception on *nix machines.

Issue: SPR-11334

Issue: SPR-11250

JXL had no release since 2009, and has some serious bugs remaining: e.g. JXL on Unix cannot read template files created on Windows, using the 'latest' JXL 2.6.12 release.

Issue: SPR-11334

JExcelAPI 2.6.12 appears to be causing ArrayIndexOutOfBoundsException
with the build. Rolling back to the earlier version for now

The @Header annotation in spring-messaging now resolves values from the
nested "nativeHeaders" map as well as top-level header map values.

In case of ambiguity (a value that exists in both), the top-level map
value is used and a warning message is printed. This is unlikly in most
cases but can be resolved by prefixing the header value with
"nativeHeadres.myHeader".

Issue: SPR-11326

Issue: SPR-11128

Issue: SPR-11128