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
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
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.
Before this change MvcUriComponentsBuilder could not create a
UriComponentsBuilder for methods where the mapping has a URI variable
and no matching method argument for it.
For example a URI variable may be in the type-level mapping but not
all methods may have an @PathVariable argument for it.
This fix addresses the shortcoming such that MvcUriComponentsBuilder
expands the method argument values available to it and leaves remaining
URI variables to be further expanded via UriComponents.expand().
Issue: SPR-11391
This commit fixes some formatting issues in the 'TestContext Framework
support classes' section of the reference manual that were introduced
in the conversion from DocBook to AsciiDoc.
Headers provided to the SimpMessagingTemplate's convertAndSend methods
are now automatically moved into the "nativeHeaders" sub-map. This
ensures the headers will go out with the STOMP message and be received
by subscribers.
Issue: SPR-11387
This commit introduces static verify() and reset() methods in
AnnotationDrivenStaticEntityMockingControl for programmatic control
on the mock.
Issue: SPR-11395
Juergen Hoeller
Rossen Stoyanchev
Sam Brannen
Rob Winch
Anton Bobov
Dave Brosius