Before this change, when a client subscribed to a "user" destination
(e.g. /user/foo), actual messages received in response to that
subscription contained the server-translated, unique user destination
(e.g. /foo-user123).

This is not an issue for clients such as stomp.js since the
subscription is unique and sufficient to match subscription responses.
However, other STOMP clients do additional checks on the destination
of the subscription and the response.

This change ensures that messages sent to clients on user destionations
always contain a destination that matches the one on the original
subscription.

Issue: SPR-11423

Issue: SPR-11426

Issue: SPR-11425

Issue: SPR-11424

* SPR-10785:
  Fix CGLIB memory leak for method injection

This commit continues the work for fixing memory leaks resulting from
CGLIB subclass generation for beans relying on method injection.

- Set proxy callbacks on the CGLIB Factory (i.e., the instance) instead
  of in the generated subclass (i.e., via the Enhancer).

- Convert private inner classes in CglibSubclassingInstantiationStrategy
  to private static classes in order to avoid unnecessary coupling to
  classes generated using CGLIB.

- Tidy up XmlBeanFactoryTests.

- Update logic in serializableMethodReplacerAndSuperclass() so that it
  finally aligns with the decision made for SPR-356.

Issue: SPR-10785, SPR-356

This commit introduces a test in XmlBeanFactoryTests that verifies that
CGLIB generated subclasses for method injected beans are reused across
bean factories for identical bean definitions. In other words, by
verifying that the same CGLIB generated class is reused for identical
bean definitions, we can be certain that Spring is no longer generating
identical, duplicate classes that consume memory in the VM.

Issue: SPR-10785, SPR-11420

Issue: SPR-11422

Issue: SPR-11422

Just implementing common custom subclass behavior out-of-the-box...

Issue: SPR-11417

Prior to this commit, the inclusion of the 'overloaded' flag in the
implementations of equals() and hashCode() in MethodOverride could lead
to adverse effects in the outcome of equals() in AbstractBeanDefinition.

For example, given two bean definitions A and B that represent the
exact same bean definition metadata for a bean that relies on method
injection, if A has been validated and B has not, then A.equals(B) will
potentially return false, which is not acceptable behavior.

This commit addresses this issue by removing the 'overloaded' flag from
the implementations of equals() and hashCode() for MethodOverride.

Issue: SPR-11420

Issue: SPR-11416

Issue: SPR-11281

Issue: SPR-11413

Also throws IllegalStateException instead of ServletException now, consistent with other Spring MVC classes.

Issue: SPR-11411

Before this change, issues surrounding the use of @Controller's in
combination with AOP proxying, resulted in an IllegalArgumentException
when trying to invoke the controller method.

This change detects such cases proactively and reports them with a
clear recommendation to use class-based proxying when it comes to
@Controller's. This is the most optimcal approach for controllers
in many respects, also allows @mvc annotations to remain on the
class.

The documentation has also been updated to have a specific section
on @Controller's and AOP proxying providing the same advice.

Issue:SPR-11281

Before this change the getPathWithinServletMapping method of
UrlPathHelper could not work properly when a default servlet mapping
(i.e. "/") was used in combination with urlDecode=false. The fact that
the getServletPath() method of HttpServletRequest always returns a
decoded path was getting in the way.

Although there is no way to check Servlet mappings through the Servlet
API, this change aims to detect the given scenario and returns the full
path following the context path thus avoiding URL decoding.

Note that the same can be achieved by setting urlDecode=false and
alwaysUseFullPath=true. However this change ensures that urlDecode
works properly without having to know that.

Issue: SPR-11101

Issue: SPR-11412

Fix example in Javadoc for ResultActions.andExpect()

mimeType is not a valid method on ContentResultMatche.

I have signed and agree to the terms of the SpringSource Individual
Contributor License Agreement.

- Consistent importing of org.junit.Assert.*;
- Proper declaration of expected exceptions via @test(expected).
- Renamed SpEL ExpressionTestCase to AbstractExpressionTests.
- Formatting and test method naming conventions.

AssertionFailedError was thrown by JUnit 3.8. Since RedirectViewTests
has been upgraded to JUnit 4, now standard java.lang.AssertionErrors are
thrown. Thus, attempting to catch an AssertionFailedError is futile.

Of course, since these tests have not been failing, it is likely a moot
point, but changing the try-catch blocks to catch a possible
AssertionError can't be a bad thing.