This change introduces a new ResponseBodyInterceptor interface that can
be used to modify the response after @ResponseBody or ResponseEntity
methods but before the body is actually written to the response with the
selected HttpMessageConverter.
The RequestMappingHandlerAdapter and ExceptionHandlerExceptionResolver
each have a property to configure such interceptors. In addition both
RequestMappingHandlerAdapter and ExceptionHandlerExceptionResolver
detect if any @ControllerAdvice bean implements ResponseBodyInterceptor
and use it accordingly.
Issue: SPR-10859
This feature required support for response exposure on Servlet/PortletRequestAttributes, instead of just in the Servlet/PortletWebRequest subclasses.
Issue: SPR-11795
Spring MVC now supports Jackon's serialization views for rendering
different subsets of the same POJO from different controller
methods (e.g. detailed page vs summary view).
Issue: SPR-7156
Before this change UrlTag expanded URI vars and encoded them using
UriUtils.encodePath.
This change makes it possible to expand using
UriUtils.encodePathSegment, which means a "/" is encoded as "%2F".
To expand with path segment semantics, prefix the URI var name "/":
<spring:url value="/url/path/{/var}">
<spring:param name="var" value="my/Id" />
</spring:url>
Issue: SPR-11401
This change adds a strategy for assigning a default name to an
@RequestMapping controller method. The @RequestMapping annotation
itself now has a name attribute allowing the explicit assignment
of a mapping name.
This is mainly intended for use in EL expressions in views. The
RequestContext class now provides a getMvcUrl method that internally
delegates to MvcUriComponents to look up the handler method.
See the Javadoc of MvcUriComponents.fromMappingName.
Issue: SPR-5779
The configured prefix should not begin with a "/", since
PublicResourceUrlProvider is already taking path mapping into account
when resolving resources and URLs.
- ResourceResolver and ResourceResolverChain now have a consistent API
with regard to method names and terminology.
- ResourceResolver and ResourceResolverChain now accept
List<? extends Resource> instead of List<Resource> for simplified
programmatic use.
- Improved Javadoc across the package.
- Formatted code to align with standards.
- Removed all references to ResourceUrlPathTranslator.
Issue: SPR-10933
An initial commit with expanded support for static resource handling:
- Add ResourceResolver strategy for resolving a request to a Resource
along with a few implementations.
- Add PublicResourceUrlProvider to get URLs for client-side use.
- Add ResourceUrlEncodingFilter and
PublicResourceUrlProviderExposingInterceptor along with initial
MVC Java config support.
Issue: SPR-10933
Previously, the use of Assume.group(CUSTOM_COMPILATION) in
AbstractJasperReportsTests excluded all JR tests when executing in the
IDE (e.g., Eclipse). This commit executes the assumption only where
necessary.
This reverts commit 3474afb165.
Unfortunately this change is likely to cause issues for applications
that use regular expressions in a URI variable. I think we will have
to leave at: if there are any dots in the last segment of the
request path, regardless of whether they're in a URI var or not,
the suffix pattern match is off.
Issue: SPR-11532
After this change dots inside URI variables in a request mapping
pattern are ignored and no longer considered an indication that
the pattern contains a suffix itself.
Issue: SPR-11532
In addition to the target parameter values (SPR-9657), the target
parameter names must also be decoded to be able to match
them to the parameter names of incoming requests.
Issue: SPR-11504
- Deleted empty AbstractWebSocketClientTests class.
- AbstractServletHandlerMethodTests and AbstractHttpRequestTests are
now actually declared as abstract.
- The following classes are not abstract but currently have an
"Abstract" prefix and therefore get ignored by the Gradle build.
This commit renames each of these by deleting the "Abstract" prefix.
- AbstractFlashMapManagerTests
- AbstractMappingContentNegotiationStrategyTests
- AbstractSockJsServiceTests
- AbstractWebSocketHandlerRegistrationTests
Prior to this commit, one had to provide her own
RequestMappingHandlerMapping instance (i.e extend
WebMvcConfigurationSupport and override the requestMappingHandlerMapping
method) in order to customize path matching properties on that bean.
Since SPR-10163, XML config users can do that using the
<mvc:path-matching/> XML tag. This commit adds the same feature to MVC
Java config with a PathMatchConfigurer.
Issue: SPR-11486
- 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
Fix testPrintFormattedScopedAttributeResult test in org.springframework.web.servlet.tags.EvalTagTests class by making an assertion which is not locale dependent.
Issue: SPR-11392
Prior to this commit, parts of a multipart HTTP request could be
injected in @RequestPart and @RequestParam annotated arguments, when
using types:
* MultipartFile, Collection<MultiPartFile>
* javax.servlet.Part, Collection<Part>
This commits updates @RequestParam and @RequestPart argument resolvers
and now allows the array versions of those types:
* Part[]
* MultiPartFile[]
Note that the MockHtpServletRequest backing tests for standard
Servlets implementations now uses a MultiValueMap to store parts
(versus a simple hashmap).
Issue: SPR-11353
This change makes it possible to provide no configuration for the
DispatcherServlet when extending
AbstractAnnotationConfigDispatcherServletInitializer, and therefore
provide all config through the "root" context.
Issue: SPR-11357
Prior to this commit, it was necessary to override
the HandlerMapping definition to change properties
like useSuffixPatternMatch, useSuffixPatternMatch...
Also, one couldn't set custom pathmatcher/pathhelper
on RequestMappingHandlerMapping via XML configuration.
This commits adds a new "mvc:annotation-driven"
subelement called "mvc:path-matching" for the tag
that allows to configure such properties:
* suffix-pattern
* trailing-slash
* registered-suffixes-only
* path-matcher
* path-helper
Note: this is a new take on this issue, since
96b418cc has been reverted by e2b99c3.
Issue: SPR-10163
This reverts commit 96b418cc8a,
"Make RequestMappingHandlerMapping xml config easier".
This implementation makes the mvc:annotation namespace less readable,
and future configuration items would add even more to this namespace.
Issue: SPR-10163
Allow HttpHeader instances to be returned directly from MVC controller
methods managed by HandlerMethodReturnValueHandler rather than needing
to be wrapped in a ResponseEntity.
Issue: SPR-11129
