Delete legacy JUnit 3.8 test from spring-test
Delete legacy JUnit 3.8 test from spring-test
Fix test bug related to legacy JUnit AssertionFailedError

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.
Polish test classes

- 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.
Remove trailing whitespace from source code
Polish Javadoc for LookupOverride and related code
Upgraded to JasperReports 5.5.1
Polishing
Revised ExcelViewTests
Delete unused imports
Fixed example in JavaDoc.

mimeType is not a valid method on ContentResultMatche.

I have signed and agree to the terms of the SpringSource Individual
Contributor License Agreement.
Merge pull request #458 from abobov/master

Fix example in Javadoc for ResultActions.andExpect()
Update javadoc to conform to JDK8 styling

Issue: SPR-11412
Fix issue w/ use of UrlPathHelper's urlDecode property

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
Improve info on use of @Controller's with aop proxying

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
MarshallingView should not close response OutputStream after copying to it

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

Issue: SPR-11411
Consistently avoid close() call on Servlet OutputStream

Issue: SPR-11413
Revised InvocableHandlerMethod exception handling

Issue: SPR-11281
Ignore container callback and marker interfaces for auto-proxy decisions

Issue: SPR-11416
AbstractHandlerMethodMapping should reuse BeanFactory.getType result