Introduction

Struts is an open source framework for building Web applications based on the model-view-controller (MVC) architecture. The Struts framework provides its own controller component and integrates with other technologies to provide the model and the view. The primary focus of this framework is to provide a control layer for the Web application, reducing both construction time and maintenance costs.

The Tiles framework builds on the jsp:include feature of Java™ Server Pages (JSP) architecture, and comes bundled with the Struts Web application framework. This framework helps to reduce the duplication between JSP files, as well as make layouts flexible and easy to maintain. The Tiles structure provides a full-featured, robust framework for assembling presentation pages from component parts.

This paper describes steps to enable caching for Struts and Tiles applications that run on IBM WebSphere Application Server. Struts and Tiles caching is an extension of servlets and JSP caching. A brief description of servlet and JSP caching follows.

Back to top

Servlet and JSP caching

Dynamic caching in WebSphere Application Server supports the caching of Java servlets and JSP files. The servlet and JSP cache can be enabled or disabled using the Web container settings in the WebSphere Application Server administrative console. In addition, the dynamic cache also requires a cache policy for each cacheable servlet and JSP file. This policy defines a set of rules for the cache to decide when and how to cache an object. These rules are stored in the cachespec.xml file. (See the WebSphere Application Server Information Center for more information.)

Because all JSP files are compiled into servlets by WebSphere Application Server, JSP files and servlets are identical from the viewpoint of the dynamic cache. The same set of rules applies for servlets and JSP files. For example, here is a sample cache policy for the servlet com.ibm.sample.TimeStampServlet.class, which has a servlet-mapping of /TimeStamp.

<cache-entry>
	<class>servlet</class>
	 <name>/TimeStamp</name>
	<cache-id>
		<component id="location" type="parameter">
			<required>true</required>
		</component>
		<timeout>180</timeout>
	</cache-id>
</cache-entry>

In this example, the servlet response is cached based on the request parameter location. In addition to the request parameter, the servlet and JSP responses can also be cached based on the request attribute, servlet path, pathinfo, HTTP session, request header, request locale, and cookie.

The <name> element defines either a fully qualified class name or the URI of a servlet and JSP file. In WebSphere Application Server releases prior to V6.0, only one cache policy (that is, <cache-entry> ... </cache-entry> in the cachespec.xml file) is permitted for each servlet and JSP file. A one-to-one mapping existed between the cache policy and the servlet class. In WebSphere Application Server V6, however, multiple cache policies are supported for a single servlet. For example, if the previously mentioned servlet has mappings /TimeStamp, /TimeStamp1 and /TimeStamp2 defined in the web.xml file, you can have three cache policies in addition to the one mentioned above for the same servlet, as shown in the following example:

<cache-entry>	
<class>servlet</class>
<name>/TimeStamp1</name>
<cache-id>
<component id="time" type="cookie">
<required>true</required>
</component>
</cache-id>
</cache-entry>

<cache-entry>
	<class>servlet</class>
	 <name>/TimeStamp2</name>
	<cache-id>
		<component id="attr" type="attribute">
			<required>true</required>
		</component>
	</cache-id>
</cache-entry>

<cache-entry>
	<class>servlet</class>
	 <name>com.ibm.sample.TimeStampServlet.class</name>
	<cache-id>
		<component id="" type="pathinfo">
			<required>true</required>
		</component>
	</cache-id>
</cache-entry>

The dynamic cache looks through the cache policies in the order in which these policies are defined in the cachespec.xml file until it finds a rule that matches the current request, then builds a cache ID using that rule.

Back to top

Struts and Tiles caching

Struts and Tiles caching is an extension of servlet and JSP caching. Enabling servlet caching using the Web container setting in the administrative console automatically enables Struts and Tiles cache. In addition to enabling the servlet cache, a cache policy is also required to cache a Struts or Tiles response.

Struts

The Struts framework provides the controller component in the MVC-style application. This controller is a servlet called org.apache.struts.action.ActionServlet.class. A servlet mapping of *.do is added for this Struts ActionServlet servlet in the web.xml file of the application so that every request for a Web address that ends with .do is processed by this servlet. The ActionServlet servlet uses the information in the struts-config.xml file to decide which Struts action class is called to actually run the request for the specified resource.

As mentioned earlier, only one cache policy is supported per servlet in releases prior to WebSphere Application Server V6, but in the case of Struts, every request URI ending in .do maps to the same ActionServlet.class. To cache Struts responses, the cache policy has to be written for the ActionServlet servlet based on its servlet path.

For example, consider two Struts actions: /HelloParam.do and /HelloAttr.do. To cache their responses based on the request parameter ID, and the request attribute arg respectively, the cache policy looks like this:

<cache-entry>
	<class>servlet</class>
	<name>org.apache.struts.action.ActionServlet.class</name>
	<cache-id>
		<component id="" type="servletpath">
		    <value>/HelloParam.do</value>
		</component>
		<component id="id" type="parameter">
		    <required>true</required>
		</component>
	</cache-id>
	<cache-id>
		<component id="" type="servletpath">
		    <value>/HelloAttr.do</value>
		</component>
		<component id="arg" type="attribute">
		    <required>true</required>
		</component>
	</cache-id>
</cache-entry>

However, in WebSphere Application Server V6, with the support for mapping multiple cache policies for a single servlet, the previous cache policy can be rewritten like this:

<cache-entry>
	<class>servlet</class>
	<name>/HelloParam.do</name>
	<cache-id>
	         <component id="id" type="parameter">
		    <required>true</required>
	          </component>
	</cache-id>
</cache-entry>
<cache-entry>
	<class>servlet</class>
	<name>/HelloAttr.do</name>
	<cache-id>
	         <component id="arg" type="attribute">
		    <required>true</required>
	          </component>
	</cache-id>
</cache-entry>

Tiles

Because the Tiles framework is built on the jsp:include tag, everything that applies to JSP caching also applies to Tiles. Similar to the jsp:include case, the fragments included using the tiles:insert tag are cached correctly only if the flush attribute is set to true. The only extra feature is caching based on the tiles attribute. For example, consider a page layout defined using the Tiles templating feature, as shown in this layout.jsp file:

<html>
<body>
    <%String categoryId = request.getParameter("categoryId")+"test";%>
	<tiles:insert attribute="header">
		<tiles:put name="categoryId" value="<%= categoryId %>" />
	</tiles:insert> 	
	<TD width="70%" valign="top">
<tiles:insert attribute="body"/>
       </TD>
	<TR>
	<TD colspan="2"><tiles:insert attribute="footer"/></TD>
	</TR>
</body>
</html>

In the above code, a tile attribute categoryId is defined using the nested tiles:put tag. This tile attribute is passed on to header.jsp when this defined layout is used in a JSP file, as shown here:

<html>
<body>
<tiles:insert page="/layout.jsp?categoryId=1002" flush="true">
	<tiles:put name="header" value="/header.jsp" />
	<tiles:put name="body" value="/body.jsp" />
	<tiles:put name="footer" value="/footer.jsp" />
</tiles:insert>
</body>
</html>

The header.jsp can retrieve the value of categoryId using <tiles:useAttribute> tag:

<HTML>
<HEAD>
<TITLE>header.jsp</TITLE>
</HEAD>
<tiles:useAttribute id="categoryId" name="categoryId" />
<%= categoryId%>
<table id="header">
<tr><td><%= System.currentTimeMillis() %></td></tr>
</table>
</HTML>

To cache the header.jsp file based on the value of the categoryId attribute, the following cache policy can be used:

<cache-entry>
	<class>servlet</class>
	<name>/header.jsp</name>
	<cache-id>
	         <component id="categoryId" type="tiles_attribute">
		    <required>true</required>
	          </component>
	</cache-id>
</cache-entry>

Back to top

Conclusion

The Struts and Tiles frameworks have been around for quite some time and have become very popular with developers for developing J2EE Web applications. Other than the differences discussed here, Struts and Tiles caching is very similar to servlet and JSP caching. Hence, enabling caching for a Struts and Tiles application is fairly simple if you are already familiar with servlet and JSP caching.

Resources

• Get involved in the developerWorks community, participate in developerWorks blogs.
  
  
• Browse for books on these and other technical topics.
  
  

About the author

Rate this article

Comments

Back to top

Table of contents

• Introduction
• Servlet and JSP caching
• Struts and Tiles caching
• Conclusion
• Resources
• About the author
• Comments

Next steps from IBM

• Try: WebSphere Application Server
• Briefing: Building SOA solutions and managing the service lifecycle
• Buy: WebSphere Application Server

Dig deeper into WebSphere on developerWorks

IBM SmartCloud trial. No charge.

Unleash the power of hybrid cloud computing today!

---

Public and private solutions in one trial.

Special offers