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 Juergen Hoeller @author Rod Johnson @see #setDefaultUrl @see #setAllowedResources @see #setApplyLastModified
| |
| |