Add "excludedExceptions" to SimpleUrlHandlerMapping

The new property can be used to ignore specific exceptions that may
otherwise be matched by the "exceptionMappings" property or resolved
through the defaultErrorView.

Issue: SPR-5193
Add CompositeRequestCondition

The new type makes it easier providing multiple custom request mapping
conditions via setters on RequestMappingHandlerMapping.

Issue: SPR-9350
Fix typo in Javadoc and emphasize @Configuration 'lite' mode
Upgrade to Gradle 1.0-rc-3

Issue: SPR-9411
Clarify @EnableScheduling javadoc

It is now advised that destroyMethod="shutdown" should be used
on @Bean methods returning an ExecutorService.

Issue: SPR-9280
Restore serializability of HttpStatusCodeException

SPR-7591 introduced a java.nio.charset.Charset field within
HttpStatusCodeException. The former is non-serializable, thus by
extension the latter also became non-serializable.

Because the Charset field is only used for outputting the charset name
in HttpStatusCodeException#getResponseBodyAsString, it is reasonable to
store the value returned by Charset#name() instead of the actual Charset
object itself.

This commit refactors HttpStatusCodeException's responseCharset field to
be of type String instead of Charset and adds tests to prove that
HttpStatusCodeException objects are once again serializable as expected.

Issue: SPR-9273, SPR-7591
Translate SQLTimeoutException to QueryTimeoutException

SPR-7680 added QueryTimeoutException to Spring's DataAccessException
hierarchy, but did not integrate it into the
SQLExceptionSubclassTranslator; it was added mainly to accomodate users
defining their own custom exception translators.

However, it does make sense to translate any SQLTimeoutException to this
new QueryTimeoutException type, and this commit makes that change. It
does represent a slight backward-incompatibility, given that
QueryTimeoutException extends TransientDataAccessException, whereas
SQLExceptionSubclassTranslator previously returned the more specific
TransientDataAccessResourceException for any SQLTimeoutException.

It is expected that this incompatibily will be very low-impact, i.e. not
affecting many (if any) users. In any case, a major release (Spring 3.2)
is the right time to introduce such a change, and the migration path is
straightforward: any users depending on catching
TransientDataAccessResourceException in the case of query timeouts
should update those catch blocks to expect QueryTimeoutException
instead. Care should also be taken to ensure correctness of existing
catch blocks expecting TransientDataAccessException, as these blocks
will now catch QueryTimeoutException as well.

Issue: SPR-9376, SPR-7680
Fix broken javadoc link to ROME tools project

Issue: SPR-9379
Fix broken link to JavaBean customization tutorial

Issue: SPR-9408
Investigate claims made in SPR-9051 regarding transactional tests

The claim: given an integration test class that is annotated with 
@ContextConfiguration and declares a configuration class that is missing

an @Configuration annotation, if a transactional test method (i.e., one 
annotated with @Transactional) changes the state of the database then
the 
changes will not be rolled back as would be expected with the default 
rollback semantics of the Spring TestContext Framework (TCF).

TransactionalAnnotatedConfigClassWithAtConfigurationTests is a concrete 
implementation of AbstractTransactionalAnnotatedConfigClassTests that
uses 
a true @Configuration class and thereby demonstrates the expected
behavior 
of such transactional tests with automatic rollback.

TransactionalAnnotatedConfigClassesWithoutAtConfigurationTests is a 
concrete implementation of
AbstractTransactionalAnnotatedConfigClassTests 
that does NOT use a true @Configuration class but rather a 'lite mode'
configuration class (see the Javadoc for @Bean for details).

Using such a 'lite mode' configuration class results in the following:

 - Its @Bean methods act as factory methods instead of singleton beans.
 - The dataSource() method is invoked multiple times instead of once.
 - The test instance and the TCF operate on different data sources.
 - The transaction managed (and rolled back) by the TCF is not the 
   transaction that the application code or test instance uses.

Ultimately, the use of a 'lite mode' configuration class gives the false
appearance that there is a bug in the TCF (in that the transaction is
not 
rolled back); however, the transaction managed by the TCF is in fact 
rolled back.

In conclusion, these tests demonstrate both the intended behavior of the

TCF and the fact that using 'lite mode' configuration classes can lead
to 
confusing results (both in tests and production code).

Issue: SPR-9051
Add MessageCodesResolver hook to WebMvcConfigurer

This change makes it possible to provide a custom MessageCodesResolver
through the MVC Java config whether using @EnableWebMvc and extending
WebMVcConfigurerAdapter or sub-classing directly from
WebMvcConfigurationSupport.

Issue: SPR-9223
Disable tx annotated tests until working within the build

Issue: SPR-9051
Add option to set Content-Length in JSON Views

MappingJackson2JsonView and MappingJacksonJsonView now provide an
option that will set the Content-Length header of JSON responses.
Use of the option implies buffering of the response and it must be
enabled explicitly.

Issue: SPR-7866
Fix tx annotated tests so that they pass in the build

AbstractTransactionalAnnotatedConfigClassTests is now annotated with
@DirtiesContext(classMode = ClassMode.AFTER_EACH_TEST_METHOD) so 
that side-effects between tests are avoided.

Re-enabled TransactionalAnnotatedConfigClassWithAtConfigurationTests
and TransactionalAnnotatedConfigClassesWithoutAtConfigurationTests.

Also introduced a log4j FileAppender for tests that writes to
"build/spring-test.log".

Issue: SPR-9051
Fix regression in ClassPathResource descriptions

ClassPathResource.getDescription() now returns consistent, meaningful
results for all variants of ClassPathResource's constructors.

Issue: SPR-9413
Avoid NPE in AutowiredAnnotationBeanPostProcessor

Prior to this change, AABPP#determineRequiredStatus never checked the
return value of ReflectionUtils#findMethod when searching for a
'#required' attribute. This call returns null for annotations such as
@Inject, @Value and @Resource, and subsequently causes a
NullPointerException to be thrown when ReflectionUtils#invokeMethod is
called. The NPE is caught immediately and #determineRequiredStatus
returns defaulting to true, but this this approach is inefficient. It
is also problematic for users who have set breakpoints on NPE -- they
end up debugging into Spring internals, which is a false positive.

This commit checks the return value of of ReflectionUtils#findMethod,
and in the case of null, eagerly returns true.  There is no change to
external behavior, simply a more efficient and debugging-friendly
implementation.

Existing test cases already cover this change, given that it is purely
a refactoring.

Issue: SPR-9316
Merge pull request #64 from marschall/SPR-9316

* SPR-9316:
  Avoid NPE in AutowiredAnnotationBeanPostProcessor
Optimize memory usage in factory *Metadata classes

InjectionMetadata and LifecycleMetadata can end up having mostly empty
instance variables. In such cases memory usage can be improved a little
bit.

This patch addresses this in two ways:

 - Creating a LinkedHashSet of the "right" size, the default capacity
   is 16 but the exact capacity needed is known in advance.

 - If the argument is empty then use Collections#emptySet which is a
   constant so no additional memory is used. Since it's immutable there
   is no need for the Collections#synchronizedSet wrapper.

Issue: SPR-9264
Merge pull request #37 from marschall/small-memory-fixes

* small-memory-fixes:
  Optimize memory usage in factory *Metadata classes
Cache MethodParameter annotation lookup results

Prior to this change, Spring's MethodParameter#getParameterAnnotations
called java.lang.Method#getParameterAnnotations on every invocation.
The latter ends up contending for a monitor inside (Sun) JDK code. This
is problematic when dealing with the high number of @RequestMapping
invocations that can occur in a Spring MVC @Controller.

This commit eliminates this contention by caching values returned by
java.lang.Method#getParameterAnnotations in a static ConcurrentMap.

Note that only Method parameter annotations are cached, while
Constructor parameter annotations are not. This is because the
issue of primary concern is, as mentioned above, @RequestMapping
methods. By nature, constructors are called much more infrequently, and
in most cases in a single-threaded fashion.

Issue: SPR-9298