Class#getDeclaredMembers returns arbitrary results under JDK7. This
results in non-deterministic execution of JUnit test methods, often
revealing unintended dependencies between methods that rely on a
specific order to succeed.

JUnit 4.11 contains support for predictable test ordering [1], but at
the time of this commit, JUnit 4.11 has not yet been released.
Therefore we are testing against a snapshot version [2], which has been
uploaded to repo.springsource.org [3] for easy access. Note that this
artifact may be removed when JUnit 4.11 goes GA.

 - Care has been taken to ensure that spring-test's compile-time
   dependency on JUnit remains at 4.10. This means that the spring-test
   pom.xml will continue to have an optional <dependency> on JUnit
   4.10, instead of the 4.11 snapshot.

 - For reasons not fully understood, the upgrade to the 4.11 snapshot
   of junit-dep caused NoSuchMethodErrors around certain Hamcrest
   types, particularly CoreMatchers and Matchers. import statements
   have been updated accordingly throughout affected test cases.

 - Runtime errors also occurred around uses of JUnit @Rule and
   ExpectedException. These have been reverted to use simpler
   mechanisms like @test(expected) in the meantime.

 - Some test methods with order-based dependencies on one another have
   been renamed in order to fall in line with JUnit 4.11's new method
   ordering (as opposed to actually fixing the inter-test
   dependencies). In other areas, the fix was as simple as adding a
   tearDown method and cleaning up state.

 - For no apparent reason, the timeout in AspectJAutoProxyCreatorTests'
   testAspectsAndAdvisorNotAppliedToPrototypeIsFastEnough method begins
   to be exceeded. Prior to this commit the timeout value was 3000 ms;
   on the CI server under Linux/JDK6 and JDK7, the test begins taking
   anywhere from 3500-5500 ms with this commit. It is presumed that
   this is an incidental artifact of the upgrade to JUnit 4.11. In any
   case, there are no changes to src/main in this commit, so this
   should not actually represent a performance risk for Spring
   Framework users. The timeout has been increased to 6000 ms to
   accommodate this situation.

[1]: https://github.com/KentBeck/junit/pull/293
[2]: https://github.com/downloads/KentBeck/junit/junit-dep-4.11-SNAPSHOT-20120805-1225.jar
[3]: https://repo.springsource.org/simple/ext-release-local/junit/junit-dep/4.11.20120805.1225

Issue: SPR-9783

Issue: SPR-9754

Update the ReflectiveAspectJAdvisorFactory class to sort candidate
AOP methods based on their annotation first and method name second.

Prior to this the order of aspects created from annotated methods
could differ depending on the underling JVM, as first noticed under
JDK7 in SPR-9729.

 - ConvertingComparator and InstanceComparator have been introduced in
   support of this change, per SPR-9730.

 - A shared static INSTANCE field has been added to ComparableComparator
   to avoid unnecessary instantiation costs within ConvertingComparator
   as well as to prevent generics warnings during certain caller
   scenarios.

Issue: SPR-9729, SPR-9730

This change makes it possible to use the RestTemplate to read an HTTP
response into a target generic type object. The RestTemplate has three
new exchange(...) methods that accept ParameterizedTypeReference -- a
new class that enables capturing and passing generic type info.
See the Javadoc of the three new methods in RestOperations for a
short example.

To support this feature, the HttpMessageConverter is now extended by
GenericHttpMessageConverter, which adds a method for reading an
HttpInputMessage to a specific generic type. The new interface
is implemented by the MappingJacksonHttpMessageConverter and also by a
new Jaxb2CollectionHttpMessageConverter that can read read a generic
Collection where the generic type is a JAXB type annotated with
@XmlRootElement or @XmlType.

Issue: SPR-7023

 - renamed resolveParameterizedReturnType() to
   resolveReturnTypeForGenericMethod()
 - fleshed out Javadoc for resolveReturnType() and
   resolveReturnTypeForGenericMethod() regarding declaration of formal
   type variables
 - improved wording in log statements and naming of local variables
   within resolveReturnTypeForGenericMethod()

Issue: SPR-9493

For legacy reasons, a MockEnvironment implementation already exists in multiple places within Spring's test suite; however, it is not available to the general public.

This commit promotes MockEnvironment to a first-class citizen in the spring-test module, alongside the existing MockPropertySource.

In addition, the following house cleaning has been performed.

 - deleted MockPropertySource from the spring-expression module
 - deleted MockEnvironment from the "spring" integration testing module
 - updated test copies of MockPropertySource and MockEnvironment
 - documented MockEnvironment and MockPropertySource in the testing
   chapter of the reference manual

Issue: SPR-9492

Prior to this change, PropertySourcesPropertyResolver (and therefore
all AbstractEnvironment) implementations failed to resolve nested
placeholders as in the following example:

    p1=v1
    p2=v2
    p3=${v1}:{$v2}

Calls to PropertySource#getProperty for keys 'p1' and 'v1' would
successfully return their respective values, but for 'p3' the return
value would be the unresolved placeholders. This behavior is
inconsistent with that of PropertyPlaceholderConfigurer.

PropertySourcesPropertyResolver #getProperty variants now resolve any
nested placeholders recursively, throwing IllegalArgumentException for
any unresolvable placeholders (as is the default behavior for
PropertyPlaceholderConfigurer). See SPR-9569 for an enhancement that
will intoduce an 'ignoreUnresolvablePlaceholders' switch to make this
behavior configurable.

This commit also improves error output in
PropertyPlaceholderHelper#parseStringValue by including the original
string in which an unresolvable placeholder was found.

Issue: SPR-9473, SPR-9569

Currently, if a factory method is parameterized and the corresponding
variable types are declared on the method itself instead of on the
enclosing class or interface, Spring always predicts the return type to
be Object, even if the return type can be explicitly inferred from the
method signature and supplied arguments (which are available in the bean
definition).

This commit introduces a new resolveParameterizedReturnType() method in
GenericTypeResolver that attempts to infer the concrete type for the
generic return type of a given parameterized method, falling back to the
standard return type if necessary. Furthermore,
AbstractAutowireCapableBeanFactory now delegates to
resolveParameterizedReturnType() when predicting the return type for
factory methods.

resolveParameterizedReturnType() is capable of inferring the concrete
type for return type T for method signatures similar to the following.
Such methods may potentially be static. Also, the formal argument list
for such methods is not limited to a single argument.

 - public <T> T foo(Class<T> clazz)
 - public <T> T foo(Object obj, Class<T> clazz)
 - public <V, T> T foo(V obj, Class<T> clazz)
 - public <T> T foo(T obj)

Issue: SPR-9493

This turns out not to be the main problem exposed in SPR-9498
but it seems like a sensible addition anyway.

Avoid Eclipse classpath conflicts between test versions of @Qualified
and @Autowired living in spring-core and actual versions living in
spring-beans.

The following syntax is now supported

  <beans profile="p1,!p2">

  @Profile("p1", "!p2")

indicating that the <beans> element or annotated component should
be processed only if profile 'p1' is active or profile 'p2' is not
active.

Issue: SPR-8728

Prior to this change, AbstractApplicationContext#setParent replaced the
child context's Environment with the parent's Environment if available.
This has the negative effect of potentially changing the type of the
child context's Environment, and in any case causes property sources
added directly against the child environment to be ignored. This
situation could easily occur if a WebApplicationContext child had a
non-web ApplicationContext set as its parent. In this case the parent
Environment type would (likely) be StandardEnvironment, while the child
Environment type would (likely) be StandardServletEnvironment. By
directly inheriting the parent environment, critical property sources
such as ServletContextPropertySource are lost entirely.

This commit introduces the concept of merging an environment through
the new ConfigurableEnvironment#merge method. Instead of replacing the
child's environment with the parent's,
AbstractApplicationContext#setParent now merges property sources as
well as active and default profile names from the parent into the
child. In this way, distinct environment objects are maintained with
specific types and property sources preserved. See #merge Javadoc for
additional details.

Issue: SPR-9444, SPR-9439

Issue: SPR-9439

A set of resolved placeholder references is used for circular
placeholder prevention. For complex property definitions this mechanism
would put property values with unresolved inner placeholder references
in the set, but would try to remove property values with placeholders
resolved, leaving the set in an invalid state and the mechanism broken.

This fix makes sure that the value that is put in the set is same one
that is removed from it, and by doing so avoids false positives in
reporting circular placeholders.

Issue: SPR-5369

Even though the Javadoc for Constants#toCode and #toCodeForSuffix
specifies that a null value for the 'namePrefix' and 'nameSuffix'
parameters are respectively allowed, before this change passing a null
to either would result in a NullPointerException.

This change fixes constant name lookup for null values of these params
as if an empty string had been passed instead. This way of handling a
null value is consistent with the rest of Constants class API.

Issue: SPR-8278

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

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

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

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

Issue: SPR-9413

Issues: SPR-7970

Prior to this commit, MutablePropertySources#get(String) would throw
IndexArrayOutOfBoundsException if the named property source does not
actually exist. This is a violation of the PropertySource#get contract
as described in its Javadoc.

The implementation now correctly checks for the existence of the named
property source, returning null if non-existent and otherwise returning
the associated PropertySource.

Other changes

 - Rename PropertySourcesTests => MutablePropertySourcesTests
 - Polish MutablePropertySourcesTests for style, formatting
 - Refactor MutablePropertySources for consistency

Issue: SPR-9179

Due to changes made in commit 2fa87a71 for SPR-9118,
AbstractResource#contentLength would fall into an infinite loop unless
the method were overridden by a subclass (which it is in the majority of
use cases).

This commit:

 - fixes the infinite recursion by refactoring to a while loop

 - asserts that the value returned from #getInputStream is not null in
   order to avoid NullPointerException

 - tests both of the above

 - adds Javadoc to the Resource interface to clearly document that the
   contract for any implementation is that #getInputStream must not
   return null

Issue: SPR-9161

This renaming more intuitively expresses the relationship between
subprojects and the JAR artifacts they produce.

Tracking history across these renames is possible, but it requires
use of the --follow flag to `git log`, for example

    $ git log spring-aop/src/main/java/org/springframework/aop/Advisor.java

will show history up until the renaming event, where

    $ git log --follow spring-aop/src/main/java/org/springframework/aop/Advisor.java

will show history for all changes to the file, before and after the
renaming.

See http://chrisbeams.com/git-diff-across-renamed-directories