Prior to this fix, ContextLoader(Listener)'s would overwrite any
value set directly against a WebApplicationContext's #setConfigLocation
method. This is a likely scenario when using Spring 3.1's new
WebApplicationInitializer support.

Now a check is performed to ensure that the ContextLoader init-param
value is non-null before doing the overwriting.

Added tests to ensure that all expected precedence, overwriting and
defaulting of context config locations works as expected.

Issue: SPR-8510

reworked JsonMessageConverter contribution into MappingJacksonMessageConverter, aligned with MappingJacksonHttpMessageConverter and MappingJacksonJsonView

@Transactional qualifiers match against transaction manager definitions in parent contexts as well (SPR-7679)

Prior to this change, ScheduledAnnotationBeanPostProcessor found any
@Scheduled methods against the ultimate targetClass for a given bean
and then attempted to invoke that method against the bean instance. In
cases where the bean instance was in fact a JDK proxy, this attempt
would fail because the proxy is not an instance of the target class.

Now SABPP still attempts to find @Scheduled methods against the target
class, but subsequently checks to see if the bean is a JDK proxy, and if
so attempts to find the corresponding method on the proxy itself. If it
cannot be found (e.g. the @Scheduled method was declared only at the
concrete class level), an appropriate exception is thrown, explaining to
the users their options: (a) use proxyTargetClass=true and go with
subclass proxies which won't have this problem, or (b) pull the
@Scheduled method up into an interface.

Issue: SPR-8651

Prior to this change, an assumption was made in
AbstractAutowireCapableBeanFactory that any factory-method would have
zero parameters.  This may not be the case in @Bean methods.

We now look for the factory-method by name in a more flexible fashion
that accomodates the possibility of method parameters.

There remains at least one edge cases here where things could still fail,
for example a @Configuration class could have two FactoryBean-returning
methods of the same name, but each with different generic FactoryBean
types and different parameter lists. In this case, the implementation
may infer and return the wrong object type, as it currently returns
the first match for the given factory-method name.  The complexity cost
of ensuring that this never happens is not likely worth the trouble
given the very low likelihood of such an arrangement.

Issue: SPR-8762

Issue: SPR-8869

added MethodValidationInterceptor/PostProcessor for Hibernate Validator 4.2 based method validation; renamed Spring's variant of @Valid to @Validated

used specific SLF4J versions for running the test suites of individual modules (fixing the Hibernate Validator 4.2 upgrade)

In order to determine why classloading errors occur after
upgrading to 4.2.0.Final.

To demonstrate this error, uncomment the 4.2.0.Final dependency in
ivy.xml and run `ant test` within the .web.servlet module.

In order to determine why Ehcache classloading errors occur after
upgrading to 4.2.0.Final.

To demonstrate this error, uncomment the 4.2.0.Final dependency in
ivy.xml and run `ant test` within the .context module.

4.1/4.2 use is optional; users may compile and run against validator
versions back to 4.0.

From earlier dependence on 4.0.0.CR4.

Spring 3.1.x will upgrade to Hibernate 4.0.0.Final as soon as possible
after its release.

Pom files have also been updated to 'recommend' use of Hibernate
3.6.0.Final or better (earlier value was 3.3.1.GA).

SPR-8883 - RestTemplate.headForHeaders throws "IllegalArgumentException: No InputStream specified" on server resource which status code are 4xx

aspectjrt is a subset of aspectjweaver. Eliminate mentions of aspectjrt
where aspectjweaver is already necessary (e.g. LTW), and do not mention
aspectjweaver where only aspectrt is required (e.g. @Aspect proxying)

Also bump required version of aspect* libs from 1.5 to 1.6.8, reflecting
OSGi and pom metadata.

Issue: SPR-8896

Issue: SPR-8539

SPR-8367 - 3.1.0.M2 update of the RestTemplate for Apache HTTP Components will default to sending 2 requests on authentication and doesn't support HttpContext parameters without significant extention/rewrite

ResourceHttpRequestHandler sends content without content-type header if no media type found (SPR-7713); ResourceHttpRequestHandler and ContentNegotiatingViewResolver use consistent mime type resolution