Prior to this change, ResourceTransformers that transformed resources by
updating the links to other resources, worked only if links were
relative to the resource being transformed.
For example, when the CssLinkResourceTransformer rewrote links within
a "main.css" resource, only links such as "../css/other.css" were
rewritten.
Using relative links is a recommended approach, because it's totally
independent from the application servlet path, context path, mappings...
This change allows absolute links to be rewritten by those Transformers,
provided those links are accurate and point to existing resources.
Issue: SPR-12137
This commit changes the way a <mvc:resource-cache> can be configured
with a user defined Cache instance.
Now a reference to a CacheManager Bean and a Cache name must be
provided. This is a more flexible configuration for typical XML setups.
<mvc:resource-cache
cache-manager="resourceCache"
cache-name="test-resource-cache"/>
Issue: SPR-12129
With the new ResourceResolver abstraction and resource resolver chain
in 4.1, the assumption that resources are found by checking for the URL
path under the configured locations is no longer accurate.
A custom ResourceResolver could find resources in ways that don't
depend on a list of locations.
Issuse: SPR-12133
This change introduces a new <mvc:resource-chain/> tag that mirrors
the ResourceChainRegistration java config counterpart.
Resolvers and Transformers can be registered with bean/ref tags, and
specific tags have been created for <mvc:version-resovlver> and
<mvc:resource-cache> in order to make common configurations easier.
Note that a specific "auto-configuration" attribute on the
resource-chain allows to completely disable default registration of
Resolvers and Transformers (sane defaults considered by the Framework).
<mvc:resources mapping="/resources/**" location="/, classpath:/META-INF/">
<mvc:resource-chain>
<mvc:resource-cache cache="resourceCache"/>
<mvc:resolvers>
<mvc:version-resolver>
<mvc:fixed-version-strategy version="abc" patterns="/**/*.js"/>
<mvc:content-version-strategy patterns="/**"/>
</mvc:version-resolver>
</mvc:resolvers>
<mvc:transformers>
<bean class="org.springframework.web.servlet.resource.AppCacheManifestTransformer"/>
</mvc:transformers>
</mvc:resource-chain>
</mvc:resources>
This also fixes a typo in the class name of
AppCacheManifestResourceTransfo*r*mer.
Issue: SPR-12129
This change separates out resource chain related methods previously in
ResourceHandlerRegistration into a new class ResourceChainRegistration
with the goal of improving readability.
Along with that, the registration of caching resolver and transformer
is now explicitly controled with a boolean flag (on the method used
to obtain the ResourceChainRegistration) and an overloaded method
also allows providing a Cache instance.
Issue: SPR-12124
This change moves the VersionStrategy builder-style methods from
ResourceHandlerRegistration to VersionResourceResolver.
This makes the methods more universally usable and also makes use of
ResourceHandlerRegistration more readable, i.e. simply a sequence of
addResource and addTransformer calls.
The ResourceHandlerRegistration now checks if the last resolver is an
instance of PathResourceResolver and if so it skips adding it.
This change also creates and adds the VersionResourceResolver (as well
as CssLinkTransformer) the first time any VersionStrategy is
registered. This ensures that custom resolvers (including an extension
of PathResourceResolver) may be added both before and after the
VersionResourceResolver.
Lastly this change renames addVersion and addVersionHash to be
consistent with addVersionStrategy.
Issue: SPR-12124
This change enables the ability to configure
ViewNameMethodReturnValueHandler & ModelAndViewMethodReturnValueHandler
with patterns to use to test for a custom redirect view name.
Issue: SPR-12054
This commit adds support for XML serialization/deserialization based on
the jackson-dataformat-xml extension. When using @EnableWebMvc or
<mvc:annotation-driven/>, Jackson will be used by default instead of JAXB2
if jackson-dataformat-xml classes are found in the classpath.
This commit introduces MappingJackson2XmlHttpMessageConverter and
MappingJackson2XmlView classes, and common parts between JSON
and XML processing have been moved to AbstractJackson2HttpMessageConverter
and AbstractJackson2View classes.
MappingJackson2XmlView supports serialization of a single object. If the model
contains multiple entries, MappingJackson2XmlView.setModelKey() should be
used to specify the entry to serialize.
Pretty print works in XML, but tests are not included since a Woodstox dependency
is needed, and it is better to continue testing spring-web and spring-webmvc
against JAXB2.
Issue: SPR-11785
Replace references to the old RFC 2616 (HTTP 1.1) with references
to the new RFCs 7230 to 7235.
This commit also deprecates:
- HttpStatus.USE_PROXY
- HttpStatus.REQUEST_ENTITY_TOO_LARGE in favor of HttpStatus.PAYLOAD_TOO_LARGE
- HttpStatus.REQUEST_URI_TOO_LONG in favor of HttpStatus.URI_TOO_LONG
Issue: SPR-12067
This change adds new methods in the ResourceHandlerRegistration API
for registering ResourceResolvers and ResourceTransformers, allowing
to better handle server-side resources in web applications.i
Here is an example of configuration for an HTML5 web application
that uses JavaScript and HTML5 appcache manifests:
registry.addResourceHandler("/**")
.addResourceLocations("classpath:static/")
.addTransformer(new AppCacheManifestTransfomer())
.addVersion("v1", "/**/*.js")
.addVersionHash("/**");
Issue: SPR-11982
Before this change if Velocity Spring form macro was bound to a path
which contains square brackets, those brackets would also appear in id
of generated tag, making the id invalid.
As of this fix all Velocity Spring form macros generate tag with id
that does not contain square brackets.
Issue: SPR-5172
This change adds support for configuring redirect view controllers and
also status controllers to the MVC Java config and the MVC namespace.
Issue: SPR-11543
This change makes it possible to configure RedirectView such that the
query string of the current request is added to the target URL.
This change is preparation for SPR-11543.
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
