This change two new capabilities to ParameterizableViewController:
- configure a View instance (in addition to view name)
- configure response status code
The status code may be useful to send a 404 while also writing to the
body using a view.
The status code may also be used to override the redirect status code
of RedirectView. Even today it's possible to configure a "redirect:"
prefixed view name but the status code could not be selected. When a
3xx status is set, the code is passed on to the RedirectView while the
view name is automatically prefixed with "redirect:" (if not already).
For full control over RedirectView it is now also possible to
parameterize the controller with a View instance.
As one more possible resulting variation, given status 204 and no view
the request is considered handled (controller returns null).
This change is preparation for SPR-11543.
Since the MVC Java config always registers a ViewResolver (composite)
bean, at a very minimum we must add an InternalResourceViewResolver
consistent with default DispatcherServlet configuration and by
extension with the MVC namespace which falls back on DispatcherServlet
implicity if no <view-resolvers> element is present.
Issue: SPR-7093
After some further discussion:
The MVC config simplifies ViewResolver configuration especially where
content negotiation view resolution is involved.
The configuration of the underlying view technology however is kept
completely separate. In the case of the MVC namespace, dedicated
top-level freemarker, velocity, and tiles namespace elements are
provided. In the case of the MVC Java config, applications simply
declare FreeMarkerConfigurer, VelocityConfigurer, or TilesConfigurer
beans respectively.
Issue: SPR-7093
Following the separation of FreeMarker/Velocity/TilesConfigurer-related
configuration via separate interface, simplify and streamline the
view registration helper classes which no longer have much difference
(most are UrlBasedViewResolver's).
Updates to Javadoc and tests.
Issue: SPR-7093
This change improves the support for auto-registration of FreeMarker,
Velocity, and Tiles configuration.
The configuration is now conditional not only based on the classpath
but also based on whether a FreeMarkerConfigurer for example is already
present in the configuration.
This change also introduces FreeMarker~, Velocity~, and
TilesWebMvcConfigurer interfaces for customizing each view technology.
The WebMvcConfigurer can still be used to configure all view resolvers
centrally (including FreeMarker, Velocity, and Tiles) without some
default conifguration, i.e. without the need to use the new
~WebMvcConfigurer interfaces until customizations are required.
Issue: SPR-7093
This commit improves and completes the initial MVC namespace
view resolution implementation. ContentNegotiatingViewResolver
registration is now also supported.
Java Config view resolution support has been added.
FreeMarker, Velocity and Tiles view configurers are registered
depending on the classpath thanks to an ImportSelector.
For both, a default configuration is provided and documented.
Issue: SPR-7093
Move spring-webmvc-tiles3 content to spring-webmvc, and
create a spring-webmvc-tiles2 module with Tiles 2 support.
Its allows View Resolution to configure Tiles 3 instead of Tiles 2.
Issue: SPR-7093
When using ServletUriComponentsBuilder.fromRequest, this change
makes sure that:
* the default port is used when the "X-Forwarded-Host" header is set
and no port is defined in that header value
* to use the scheme defined in the "X-Forwarded-Proto" header if set
Issue: SPR-11872
This change renames AppCacheResourceTransformer to
AppCacheManifestTransfomer, in order to avoid confusion between this
transformer and the CacheResourceTransformer (which caches
transformations done by the chain to save CPU/memory at runtime).
Issue: SPR-11964
This change adds a new ResourceTransformer that helps handling resources
within HTML5 AppCache manifests for HTML5 offline application.
This transformer:
* modifies links to match the public URL paths
* appends a comment in the manifest, containing a Hash (e.g. "# Hash:
9de0f09ed7caf84e885f1f0f11c7e326")
See http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#offline
for more details on HTML5 offline apps and appcache manifests.
Here is a WebConfig example:
@Override
public void addResourceHandlers(ResourceHandlerRegistry registry) {
AppCacheResourceTransformer appCacheTransformer =
new AppCacheResourceTransformer();
registry.addResourceHandler("/**")
.addResourceLocations("classpath:static/")
.setResourceResolvers(...)
.setResourceTransformers(..., appCacheTransformer);
}
Issue: SPR-11964
Users can not mix and match between "inner bean" argument resolver and "external bean" argument resolver. This commit only focuses only on argument-resolver, while the support could be extended to return value handlers as well.
Issue: SPR-11927
This change adds support for configuring ResourceResolvers and
ResourceTransformers with ResourceHttpRequestHandlers.
This is an example configuration:
<mvc:resources mapping="/resources/**" location="/">
<mvc:resolvers>
<bean class="org.springframework.web.servlet.resource.PathResourceResolver"/>
<ref bean="myResourceResolver"/>
</mvc:resolvers>
<mvc:transformers>
<bean class="org.springframework.web.servlet.resource.CssLinkResourceTransformer" />
</mvc:transformers>
</mvc:resources>
<bean id="myResourceResolver" class="org.example.resource.MyResourceResolver"/>
Issue: SPR-10951
This commit introduces the RequestEntity, a class similar to
ResponseEntity, but meant for HTTP requests rather than responses. The
RequestEntity can be used both in RestTemplate as well as @MVC
scenarios.
The class also comes with a builder, similar to the one found in
ResponseEntity, which allows for building of a RequestEntity through a
fluent API.
Issue: SPR-11752
Prior to this commit, one of the available strategies for resolving
resources was the PrefixResourceResolver. Reconsidering the core goal of
this resolver and the FingerprintResourceResolver, we found that the
true core feature is versioning static resources application-wide.
This commit refactors both Resolvers by:
* having only on VersionResourceResolver
* that resolver takes a mapping of paths -> VersionStrategy
* provided VersionStrategy implementations are ContentBasedVS
(previously FingerprintRR), FixedVS (previously PrefixRR)
One can add a VersionResourceResolver like this:
Map<String, VersionStrategy> versionStrategies = new HashMap<>();
versionStrategies.put("/**/*.js", new PrefixVersionStrategy("prefix"));
versionStrategies.put("/**", new ContentBasedVersionStrategy());
VersionResourceResolver versionResolver = new VersionResourceResolver();
versionResolver.setVersionStrategyMap(versionStrategies);
List<ResourceResolver> resolvers = new ArrayList<ResourceResolver>();
resolvers.add(versionResolver);
resolvers.add(new PathResourceResolver());
Issue: SPR-11871
Prior to this commit, the CssLinkResourceTransformer would transform
"external resources", i.e. resources not served by the web application.
This commit only allows transformation for resources which path don't
contain scheme such as "file://" or "http://". Only relative and
absolute paths for resources served by the webapp are valid.
Issue: SPR-11860
Since SPR-11486 and SPR-10163, Path Matching options can be configured
to customize path matching options for RequestMappingHandlerMapping.
Prior to this commit, the defined pathMatcher and pathHelper instances
were only used in RequestMappingHandlerMapping.
This commit now registers pathMatcher and pathHelper beans under
well-known names and share them with several HandlerMappings beans,
such as ViewControllerMappings and ResourcesMappings.
Issue: SPR-11753
This commit adds support for Groovy Markup templates.
Spring's support requires Groovy 2.3.1+.
To use it, simply create a GroovyMarkupConfigurer and a
GroovyMarkupViewResolver beans in the web application context.
Issue: SPR-11789
Enable JSONP support by wrapping the JSON output into
a callback when a JSONP query parameter specifying the
function name to use as callback is detected.
Default query parameter names recognized as JSONP ones
are "jsonp" and "callback". This list can be customized if
needed.
This commit also fixes JSONView support by removing
the view name specified in the model from the output.
Issue: SPR-8346
This change adds a ResourceTransformer that can be invoked in a chain
after resource resolution. The CssLinkResourceTransformer modifies a
CSS file being served in order to update its @import and url() links
(e.g. to images or other CSS files) to match the resource resolution
strategy (e.g. adding MD5 content-based hashes).
Issue: SPR-11800
The newly added support for ResponseBodyInterceptor is a good fit for
the (also recently added) support for the Jackson @JsonView annotation.
This change refactors the original implementation of @JsonView support
for @ResponseBody and ResponseEntity controller methods this time
implemented as an ResponseBodyInterceptor.
Issue: SPR-7156
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
