Struts best practices

Build the best performing large applications

True to the literal meaning of the word, "Struts" provides supporting building blocks and infrastructure components to build a Web-based application. It is an MVC-based (Model View Controller) open source framework developed and supported by the Apache Software Foundation. Because of its support for extensibility and plug-ins, the framework has picked up stupendous popularity among J2EE-based application developers. The framework can be extended and customized to suit a particular application need.

Though covering all the aspects of this framework and documenting the best practices may not be possible in one article, the subsequent sections discuss some of the best practices for developing with Struts.

The primary sources of information for this article are the Struts users' mailing list, the Struts developers' mailing list, and my experience with Struts-based applications.

The article discusses the following main points:

  • Screens with dynamic fields
  • Safeguarding JSP pages
  • Error categorization
  • Validation of service requester
  • Application security
  • Prepopulation
  • Stack maintenance (for bread crumbs)
  • Context-related problems
  • Form-bean scope
  • Data transfer object implementation
  • Exceptions
  • Action chaining

Screens with dynamic fields


The Java Community Process (JCP) has released the Java Metadata Interface Specification, and some programmers are involved in the open source project Beehive. Both of these projects strive to reduce coding. However, the question is whether Struts has a facility that can be used for writing a generic JSP (JavaServer Pages) page for specific types of screens in an application so that a separate JSP page doesn't have to be written for each screen. For example, to reduce our coding efforts, we might want to develop a generic JSP page for all search screens in an application or for submitting batch processes or reports, where the parameters to be input vary for every report/batch.

Form beans are classes that must have getter and setter methods for every field in JSP, and the problem is how to write these methods for dynamic fields.

Struts best practice

Possible solutions are:

  • Let the JSP page have fields in a specific pattern such as field1, field2, field3, and so on, and provide their getter and setter methods in the form bean. Here, the number of fields that can appear on the screen cannot be more than the number of variables in the form bean.
  • Utilize the indexed getter and setter methods available in the form bean for all dynamic fields in the JSP page.

In the second approach, an increase in the number of fields in JSP requires no alteration in any component; therefore, it is the recommended best practice. The implementation details follow:

  1. Assuming an array of strings carries the resource IDs for all the dynamic fields in the form bean, the JSP page can be written as:

    <logic:iterate name= "FormName" property="propertyName" indexId="abc" >
      <html:nested property='dynaProperty(<bean:write name="abc")'/>
  2. Declare two methods in the form bean, as shown below. These methods will work as the getter and setter methods for all the dynamic fields in the JSP page. Whatever appears in small brackets—()—in front of dynaProperty (in the JSP page as shown above), is taken as key, and either the getDynaProperty() or setDynaProperty() method from the form bean is called. These values should be stored in a HashMap against the key, which can later be retrieved in the Action class from the HashMap against the key.

    public class testVarForm extends ActionForm 
      private HashMap hMap = new HashMap();
      public testVarForm() {  }
      public void setDynaProperty(String key, Object value)  {
        this.hMap.put(key, value);
      public Object getDynaProperty(String key)   {
        return this.hMap.get(key);
      public HashMap getHashMap()   {
        return this.hMap;
      public void setHashMap(HashMap newHMap)
        this.hMap =newHMap;

Safeguard your JSP pages


When developers use Web-based applications, they often try to break into the security. The most common habit is to view the source of HTML in the browser and somehow determine the path of JSP pages and access them. The intent is to highlight the vulnerability of JSP pages accessible without authorization. Users who lack authorization to view the source might observe the source URL while sitting with another user who is authorized to work on that specific screen. Later, this unauthorized user could log in to the application and type the URL in the browser. In some cases, such users are able to make their way through.

Struts best practice

The possible solutions to this problem:

  • Do not let users access any JSP page directly. The starting page can be an HTML document. Add the following lines to the web.xml file to prevent users from accessing any JSP page directly:

  • The most popular option is to keep JSP pages behind the WEB-INF folder. This has a few tradeoffs. For example, you cannot take the JavaScript/CSS (Cascading Style Sheets) files behind WEB-INF, and if using Struts modules, you may encounter some context-related problems. Refer to the section "Context-Related Problems," which appears later in this article, to circumvent such issues.

The second approach allows some JSP pages (which are not behind WEB-INF) to be visible directly. It does not require a descriptor file entry, therefore the best practice is to keep the pages behind WEB-INF.

Error categorization


Error handling becomes complex for an n-tiered application. In a browser-based application, the errors can be handled in the client layer using JavaScript and in the Web tier or EJB (Enterprise JavaBeans) tier using custom Java methods. Building an infrastructure for consistent error reporting proves more difficult than error handling. Struts provides the ActionMessages/ActionErrorsclasses for maintaining a stack of error messages to be reported, which can be used with JSP tags like <html: error> to display these error messages to the user. The problem is reporting a different category/severity of the message in a different manner (like error, warning, or information). To do that, the following tasks are required:

  1. Register the errors under the appropriate category
  2. Identify these messages and show them consistently

Struts best practice

Struts' ActionErrors class comes in handy in resolving the first issue of stacking messages of different categories. To display the error messages of different categories, define these categories such as FATAL, ERROR, WARNING, or INFO, in an interface. Then, in the Action or form-bean class, you can use:

errors.add("fatal", new ActionError("....")); or 
errors.add("error", new ActionError("....")); or 
errors.add("warning", new ActionError("....")); or 
errors.add("information", new ActionError("....")); 

Having stacked the messages according to their category, to display them according to those categories, use the following code:

<logic:messagePresent property="error"> 
<html:messages property="error" id="errMsg" >
    <bean:write name="errMsg"/>
</logic:messagePresent >

Or use:

<logic:messagePresent property="error"> 
<html:messages property="error" id="errMsg" >
    showError('<bean:write name="errMsg"/>'); // JavaScript Function
</logic:messagePresent >

Validation of service requester: Login-check


Authentication in a Web-based application can be done in any class, depending upon whether an SSO-based (single sign-on) or a JAAS-based (Java Authentication and Authorization Service) mechanism is being used. The challenge is identifying the placeholder for checking the service requester's authenticity and the user session's validity.

Struts best practice

Usual practice is to store user credentials in HttpSession after authentication. Subsequent calls check credentials' existence in session context. The question is where to place these checks. Some options are listed below, but they must be rationalized on the basis of performance overhead, possibility of future changes, and application manageability:

  • Authenticate against the session context before doing any operation (as done in Struts-example.war's
  • Authenticate against session context in the Action class
  • Write servlet request filters that perform authentication
  • Extend RequestProcessor

The first two options require every JSP page or the Action class to perform the authentication against the session context. Change in the interface mandates change in all these JPS pages and classes. The third option is efficient, but overkill for the problem at hand.

The best practice is to extend the RequestProcessor class and perform authentication in methods such as processActionPerform() or processRoles().

Application security


The usual demand in Web-based applications is to have screen-level, function-level, data-row-level, and field-level security. If not suitably designed, incorporation of these security levels in an application may cause not only performance overheads, but also maintenance nightmares.

For all the security types mentioned above, the preferred approach is to place the security check in one class instead of in every component—i.e., in every JSP page or Action class.

Struts has a method processRoles() for screen- and function-level security checks, however nothing is provisioned for field- and column-level security types, making it the most challenging for most Struts users.

Struts best practice

Irrespective of where the security realm is set up (database or directory service), the best practices for the various security levels are described below:

  • For screen- and function-level security, extend RequestProcessor and override the method processRoles() to perform the check against a HashMap that stores a mapping of roles and screen IDs/function IDs
  • Row-level security is best implemented in the application's object relational mappings
  • For field-level security, tag libraries are extended to perform the check against the field ID



One requirement difficult to achieve is data prepopulation in a drop-down list (HTML Select tag) or in other fields. Some of these values come from a database, some from the application's context, and the rest are passed from calling screens. These values must be populated in a form bean before forwarding the control to the JSP page.

Struts best practice

The form bean's prepopulation can be accomplished using one of the following approaches:

  • The on-demand lazy-loading technique for all such data in the application's context, which is required for prepopulation. An application screen's (JSP page) invocation mechanism can always be routed though a specific method of corresponding Action classes. Prepopulation-related code can be placed in this method.
  • Have different Action classes—one for requesting and another for submitting the JSP pages. The entire module or application can share the Action class used for requesting.

The second approach works well for small applications. However, for large applications, managing numerous Action classes grows cumbersome. Therefore, the first approach should be adopted.

Stack maintenance (for bread crumbs)


What if you need to go to a JSP page from two or more different JSP pages and subsequently return to the calling JSP page? Similarly, often developers need to go to various JSP pages in a criss-cross manner, which grows more complex when breadcrumbs need to be shown. Thus, the application must remember the pages visited.

Struts best practice

The remedy is to maintain the paths of all the forwarded JSP pages in a Stack (java.util.Stack). The following steps are required for maintaining such a Stack:

  1. Extend the RequestProcessor class and override the method processActionPerform(). In the overridden method, after the call to super.processActionPerform(), ActionForward's path should be stored in the Stack.
  2. In the application's parent Action class, provide methods to traverse forward and backward in the Stack.

Another option is to utilize an already available open source project at like Open Tranquera (see Resources for more details).

Context-related issues


If ActionForward's path and the path to which the control is forwarded differ, a context problem has resulted. More such context-related problems are quite frequent in Struts-based applications, most of which can be solved using some of Struts' less exploited features.

Struts best practice

Mention the JSP page's name as a path for ActionForward and let the prefix—i.e., the JSP page's access path—come from a preconfigured place. Do that in the following manner:

struts-config.xml(s) has a controller tag; add a property in this tag named forwardPattern. This property's value can be prefixed to all the ActionForward paths. This property's default value is $M$P, which means the module prefix will be prefixed to ActionForward's path. We can change this value to anything; e.g., WEB-INF/pages/$M$P. As a result, all the ActionForward paths will be searched in the directory WEB-INF/pages/<module-prefix>/.

1 2 Page 1
Page 1 of 2
How to choose a low-code development platform