| Simple servlet that can expose an internal resource, including a
default URL if the specified resource is not found. An alternative,
for example, to trying and catching exceptions when using JSP include.
A further usage of this servlet is the ability to apply last-modified
timestamps to quasi-static resources (typically JSPs). This can happen
as bridge to parameter-specified resources, or as proxy for a specific
target resource (or a list of specific target resources to combine).
A typical usage would map a URL like "/ResourceServlet" onto an instance
of this servlet, and use the "JSP include" action to include this URL,
with the "resource" parameter indicating the actual target path in the WAR.
The defaultUrl property can be set to the internal
resource path of a default URL, to be rendered when the target resource
is not found or not specified in the first place.
The "resource" parameter and the defaultUrl property can
also specify a list of target resources to combine. Those resources will be
included one by one to build the response. If last-modified determination
is active, the newest timestamp among those files will be used.
The allowedResources property can be set to a URL
pattern of resources that should be available via this servlet.
If not set, any target resource can be requested, including resources
in the WEB-INF directory!
If using this servlet for direct access rather than via includes,
the contentType property should be specified to apply a
proper content type. Note that a content type header in the target JSP will
be ignored when including the resource via a RequestDispatcher include.
To apply last-modified timestamps for the target resource, set the
applyLastModified property to true. This servlet will then
return the file timestamp of the target resource as last-modified value,
falling back to the startup time of this servlet if not retrievable.
Note that applying the last-modified timestamp in the above fashion
just makes sense if the target resource does not generate content that
depends on the HttpSession or cookies; it is just allowed to evaluate
request parameters.
A typical case for such last-modified usage is a JSP that just makes
minimal usage of basic means like includes or message resolution to
build quasi-static content. Regenerating such content on every request
is unnecessary; it can be cached as long as the file hasn't changed.
Note that this servlet will apply the last-modified timestamp if you
tell it to do so: It's your decision whether the content of the target
resource can be cached in such a fashion. Typical use cases are helper
resources that are not fronted by a controller, like JavaScript files
that are generated by a JSP (without depending on the HttpSession).
author:
Rod Johnson
author:
Juergen Hoeller
See Also: ResourceServlet.setDefaultUrl
See Also: ResourceServlet.setAllowedResources
See Also: ResourceServlet.setApplyLastModified | 