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
Merge pull request #63 from dukehoops/SPR-9298

* SPR-9298:
  Cache MethodParameter annotation lookup results
Pattern suffix issue in AnnotationMethodHandlerAdapter

SPR-9333
Improve documentation for configuration class 'lite' mode

Overhauled the class-level JavaDoc in @Bean:

 - added h3 headers for greater clarity and readability
 - mentioned 'prototype' semantics for lite mode

Issue: SPR-9401
Fix minor grammatical errors in AbstractBeanDefinition
Fix annotation search ending too early

In AnnotationUtils#findAnnotation(Method, Class), the search for a
method annotation fails if:

 - the original method does not have the annotation

 - an abstract superclass does not have an equivalent method declared

 - an interface implemented by the superclass has the method and
   the annotation -> this should be found, but is not!

This happens because the try-catch block in #findAnnotation is too wide:
cl.getDeclaredMethod() can throw NoSuchMethodException and skip the
'#searchOnInterfaces' call prematurely.

The try-catch block was made narrower to allow #searchOnInterfaces to
be called even if the abstract class does not have the method declared
at all.

Issue: SPR-9342
Merge pull request #81 from JanecekPetr/SPR-9342

* SPR-9342:
  Fix annotation search ending too early
Improve documentation of @Bean 'lite' mode

Updated the class-level JavaDoc for @Bean to better explain the
semantics of 'lite' mode.

Renamed "Configuration Class Lite Mode" to "@Bean Lite Mode".

Added discussion of @DependsOn to the class-level JavaDoc.

Issue: SPR-9401
Improve documentation of @Bean 'lite' mode

Removed misleading mention of "configuration classes" in the
"@Bean Lite Mode" section.

Issue: SPR-9401
Fix locale parsing error with en_en, tr_tr, etc

Previously, StringUtils#parseLocaleString would parse locale strings
having the same lowercase token for both language and country
incorrectly, e.g. 'tr_tr' would parse to 'tr_TR_tr' as opposed to the
expected 'tr_TR'.

This commit fixes this behavior by using using String#lastIndexOf
instead of String#indexOf when determining the location of the country
code token.

Issue: SPR-9420