Issue: SPR-14400

Issue: SPR-14399

Issue: SPR-14393

HibernateJpaVendorAdapter and LocalSessionFactoryBuilder enforce Hibernate 5.2's connection handling mode DELAYED_ACQUISITION_AND_HOLD

Issue: SPR-14393

Issue: SPR-14393

Issue: SPR-14394

This commit updates AbstractHandlerExceptionResolver to only log at the
WARN level exceptions that are actually resolved by the
ExceptionResolver.

In case developers wish to log each time an ExceptionResolver is called,
a DEBUG level log is still available.

Issue: SPR-14392

Issue: SPR-14367

Prior to this commit, any attempt to include a bean of type
ServletServerContainerFactoryBean in the WebApplicationContext for an
integration test class annotated with @WebAppConfiguration in
conjunction the Spring TestContext Framework (TCF) would have resulted
in an IllegalStateException stating that "A ServletContext is required
to access the javax.websocket.server.ServerContainer instance."

In such scenarios, the MockServletContext was in fact present in the
WebApplicationContext; however there was no WebSocket ServerContainer
stored in the ServletContext.

This commit addresses this issue by introducing the following.

- MockServerContainer: a private mock implementation of the
  javax.websocket.server.ServerContainer interface.

- MockServerContainerContextCustomizer: a ContextCustomizer that
  instantiates a new MockServerContainer and stores it in the
  ServletContext under the attribute named
  "javax.websocket.server.ServerContainer".

- MockServerContainerContextCustomizerFactory: a
  ContextCustomizerFactory which creates a
  MockServerContainerContextCustomizer if WebSocket support is present
  in the classpath and the test class is annotated with
  @WebAppConfiguration. This factory is registered by default via the
  spring.factories mechanism.

Issue: SPR-14367

Issue: SPR-14367

Issue: SPR-14388

Issue: SPR-14373

Issue: SPR-14328

When comparing multiple matching @RequestMapping's, the HTTP method
condition has the lowest precedence. It's mainly about ensuring an
explicit mapping wins over an implicit (i.e. no method) one.

As of 4.3 HTTP HEAD is handled automatically for controller methods
that match to GET. However an explicit mapping HTTP HEAD allows an
application to take control.

This commit ensures that for HTTP HEAD requests the HTTP method
condition is checked first which means that an explicit HEAD mapping
now trumps all other conditions.

Normally we look for the most specific matching @RequestMapping.
For HTTP HEAD we now look for the most specific match among
@RequestMapping methods with a HEAD mapping first.

Issue: SPR-14383

Issue: SPR-14385

Issue: SPR-10454

Issue: SPR-14379

Even before this change SockJS sessions always cancelled the heartbeat
task first prior to sending messages. However when the heartbeat task
is already in progress, cancellation of it is not enough and we must
wait until the heartbeat is sent.

This commit adds a heartbeat write lock which is obtained and held
during the sending of a heartbeat. Now when sessions send a message
they still cancel the heartbeat task but if that fails they also wait
for the heartbeat write lock.

Issue: SPR-14356

Issue: SPR-14372

* pr/1082:
  Move <a> out of @code

Closes gh-1082

Closes gh-14366

* pr/1080:
  Polish contribution
  Fix typo in javadoc

Closes gh-1080

See gh-1080

Issue: SPR-14365

Issue: SPR-14362

Issue: SPR-14364

Issue: SPR-14358

ReflectionTestUtils invokes toString() on target objects in order to
build exception and logging messages, and prior to this commit problems
could occur if the invocation of toString() threw an exception.

This commit addresses this issue by ensuring that all invocations of
toString() on target objects within ReflectionTestUtils are performed
safely within try-catch blocks.

Issue: SPR-14363

In the process of upgrading the build to use Gradle 2.14, the
setFieldOnLegacyEntityWithSideEffectsInToString() test method in
ReflectionTestUtilsTests began to fail. The reason is that the log
level for ReflectionTestUtils is now DEBUG by default with Gradle 2.14.
The apparent cause is that log4j was present on the test runtime
classpath for the spring-test module with all previous versions of
Gradle (via a transitive optional dependency from another project that
spring-test depends on). Thus the configuration in log4j.properties in
spring-test was previously honored, but with Gradle 2.14 a different
commons logging implementation is picked up.

Thus, in addition to upgrading the build to Gradle 2.14, this commit
introduces an explicit test runtime dependency on log4j in the
spring-test module.

The discovered bug in ReflectionTestUtils regarding DEBUG log level
will be addressed separately.

Issue: SPR-14362

Issue: SPR-14355

Issue: SPR-14349

Issue: SPR-11683