The use of the HandlerMapping.PATH_WITHIN_HANDLER_MAPPING_ATTRIBUTE
in ResourceUrlProvider (as a way of saving lookup path determination)
leads to incorrect results. For example when the request is forwarded
the current requestUri may no longer be compariable to the value of the
PATH_WITHIN_HANDLER_MAPPING_ATTRIBUTE. Also where the request is mapped
using a pattern, the value of PATH_WITHIN_HANDLER_MAPPING_ATTRIBUTE is
not the same as the lookup path.
This change removes the use of the attribute from ResourceUrlProvider
and instead always determines the lookup path when getForRequestUrl
is called.
Issue: SPR-12332
Before this change, the type of asynchronously produced return values
(e.g. Callable, DeferredResult, ListenableFuture) could not be
properly determined with an actual resulting value of null. Or even
with an actual value returned, the generic type could not be properly
determined. This change fixes both of those issues.
Issue: SPR-12287
The getForRequestUrl method of ResourceUrlProvider uses the
HandlerMapping.PATH_WITHIN_HANDLER_MAPPING_ATTRIBUTE attribute to
determine the relevant portion of the resource URL path.
However there are cases when that attribute may not have a leading
(e.g. when the current URL was matched to a prefix-based pattern
and hence extracted via PathMatcher#extractPathWithinPattern), which
interferes with the matching of resource URL paths to patterns.
This change ensures a leading slash is present
Issue: SPR-12281
The resourceHandlerMapping in the MVC Java config is not configured
with any interceptors, and in particular those added through the
InterceptorRegistry, which are otherwise added to all other handler
mapping beans created by the config. This means that the
ResourceUrlProviderExposingInterceptor (added in 4.0) is also not
used for resource requests.
This change ensures the ResourceUrlProviderExposingInterceptor is
configured on the resourceHandlerMapping.
Issue: SPR-12279
Jackson2ObjectMapperBuilder now allows to create ObjectMapper and XmlMapper
instances easily thanks to its fluent API.
This builder is used in Jackson message converters and views to instantiate default
ObjectMapper and XmlMapper.
This commit also add a createXmlMapper property to
Jackson2ObjectMapperFactoryBean in order to allow to create easily a XmlMapper
instance.
Issue: SPR-12243
When not ViewResolver's have been registered, detect if the context
contains any other ViewResolver beans. If not, add InternalResourceVR
to match default DispatcherServlet behavior.
Issue: SPR-12267
This change defers determination of whether to invoke a message
converter in case of a null @ResponseBody value (or ResponseEntity with
a null body) until after the invocation of the ResponseBodyAdvice
chain. This allows a ResponseBodyAdvice to handle null values
potentially turning them into non-null value.s
Issue: SPR-12152
Prior to this change, getForRequestUrl implementation would only work
for applications with a non-empty servlet path. So web applications
mapped to "/" would trigger a IllegalStateException while checking the
current request against the request path within the current mapping.
This change relaxes this and only check that the path within mapping is
within the request URL.
Issue: SPR-12158
This change moves the resource-cache configuration to the
<resource-chain/> tag, since enabling/disabling resource cache should
be driven by a property or a SpEL expression.
So now that configuration can be set with XML attributes:
<mvc:resource-chain resource-cache="true"
cache-manager="resourceCache" cache-name="test-resource-cache">
In order to mirror the JavaConfig behavior, the "resource-cache"
attribute is required.
Issue: SPR-12129
Before this change ResourceUrlProvider used getUrlMap to detect
ResourceHttpRequestHandler instances, however the map may contain bean
names as is the case when using <mvc:resources>. Instead it now uses
getHandlerMap.
This change adds a ResourceUrlProvider bean to the
ResourceBeanDefinitionParser to match the same in the Java config.
For consistency the name of the bean in the Java config is renamed.
Also a ResourceUrlProviderExposingInterceptor is declares as a global
MappedInterceptor.
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
Rossen Stoyanchev
Juergen Hoeller
Sebastien Deleuze
Brian Clozel
Rossen Stoyanchev