Commit https://github.com/spring-projects/spring-framework/commit/2b97d6
introduced a change where the path within the DispatcherServlet is
determined with each call to ResourceUrlProvider.getForRequestUrl.

To avoid repeating that every time a URL is encoded through the
response, we now cache the result of the lookupPath determination in
ResourceUrlEncodingFilter.

Issue: SPR-12332

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

Issue: SPR-12287

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

The ViewResolverComposite that contains the ViewResolver's registered
throug the MVC Java config and namespace can now be assigned an
explicit order.

The MVC Java config and namespace now have a consistent default order
or lowest precedence.

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

Check for bean names of type rather than actual beans.

Issue: SPR-12267

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

Issue: SPR-12270

Issue: SPR-12242

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

Issue: SPR-12171

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 commit also fixes the AbstractMappingJacksonResponseBodyAdvice Javadoc.

Issue: SPR-12149

Issue: SPR-12151

Issue: SPR-12149

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 change finishes work started in SPR-12133.

Issue: SPR-12133

Issue: SPR-12119

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