The <code>mapping</code> attribute must be an Ant pattern that can be used by <classname>SimpleUrlHandlerMapping</classname>, and the <code>location</code>
attribute must specify one or more valid resource directory locations. Multiple resource locations may be specified using a comma-seperated list of values.
The locations specified will be checked in the specified order for the presence of the resource for any given request. For example, to enable the serving
of resources from both the web application root and from a known path of <code>/META-INF/public-web-resources/</code> in any jar on the classpath, the tag
When serving resources that may change when a new version of the application is deployed, it is recommended that you incorporate a version string into the
mapping pattern used to request the resources, so that you may force clients to request the newly deployed version of your application's resources. Such a
version string can be parameterized and accessed using SpEL so that it may be easily managed in a single place when deploying new versions.
</para>
<para>
As an example, let's consider an application that uses a performance-optimized custom build (as recommended) of the Dojo JavaScript library in production, and that the build is generally
deployed within the web application at a path of <code>/public-resources/dojo/dojo.js</code>. Since different parts of Dojo may be incorporated into the
custom build for each new version of the application, the client web browsers need to be forced to re-download that custom-built <code>dojo.js</code> resource
any time a new version of the application is deployed. A simple way to achieve this would be to manage the version of the application in a properties file,
such as:
</para>
<programlisting><![CDATA[
application.version=1.0.0]]>
</programlisting>
<para>
and then to make the properties file's values accessible to SpEL as a bean using the <code>util:properties</code> tag: