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>/.

For above solution to work, make sure that ActionForward's contextRelative property is marked false. If this property is marked true, the ActionForward paths will be taken since they are not modified.

Also note that for forwardPattern to work, the path of all ActionForwards must start with a /.

Form-bean scope


A well-managed session context can greatly boost application performance. It is therefore important to understand the implications of marking the form-bean scope to request, session, or application. However, the following confusions usually arise:

  • If the scope of the form beans is marked request, how will the information available in one JSP page/screen also be available to another one?
  • If the scope is session, how will the server know that the client is no longer interested in that form bean and consequently destroy it?

Struts best practice

State can be maintained in HttpSession (Web tier), in stateful session beans (EJB tier), or in a database. The appropriate choice should be based on what kind availability needs persist or whether the application is supposed to provide multichannel access. However, the rule of thumb is to maintain the state close to the tier that requires it most. Therefore, the best practice is to keep the state in HttpSession; i.e., mark the form-bean scope to session.

The important question is when and how to destroy the form beans stored in the HttpSession. The session beans should be destroyed in an extended RequestProcessor based on the least-recently-accessed, to-be-removed logic. Another approach is to destroy all the form beans as soon as the user invokes a new business operation, possibly from the application menu.

Data transfer object implementation


Usually a data transfer object (DTO) is used for shuttling data between the Web and EJB tiers. It is not a good idea to pass the view-helper class (form bean, in the case of Struts), to the EJB tier, primarily because all of the form bean's fields are of type string. A separate class should be used as the data transfer object. The problem is how to transfer the data from the form bean to the DTO.

Struts best practice

Two options are available for populating the data transfer object:

  • Create the transfer object and copy the data from the form bean to the transfer object. Data-type conversions must be handled before data copying. Similarly, on the way back, you must repeat the same exercise of copying the data from the DTO to the form bean.
  • Use Commons' BeanUtils class, which uses the Reflection API to achieve its objectives.

Developers frequently use the first option, which is not problematic except that the mundane exercise is repeated every time, resulting in bulky and ugly code. While copying data, suitable data-type conversion must be hand-coded in the DTO's setter methods, so that when data is copied from the form bean to the DTO, it converts to the appropriate business type. All the attributes of type string in the form beans are the primary reasons for data-type conversions.

You can avoid all this coding by using BeanUtils's copyProperties() method. The method copies the data from one bean to another, provided the variable names of the business attributes in the value/transfer object are the same as the ones in the form bean. The method also relieves you from data-type conversion by transparently converting source-bean attribute types to destination-bean attribute types.



As a generic principle, errors should be caught right where they occur to display meaningful error messages. To implement this principle, programmers must write their own custom exception classes, wrap the actual exception into these custom classes, and throw them back to the place where they are handled. In a Struts-based application, the exceptions thrown from the EJB/Web tier are handled either in the Action class or the form bean. The usual practice involves writing a try-catch block to catch these exceptions in the Action class or the form bean, and creating an ActionError object with user-friendly messages derived from the application property file. The decision to direct these error messages to the screen is coded in the action classes, using the ActionMapping.findForward() method.

You must code all this exception-handling code in the Action class as well as the decision to direct the message to the screen. If the error-handling strategy changes, then every Action or form bean requires changes.

Struts best practice

Struts deals with the issue of exception handling in a competent way, using declarative exception handling. This, as opposed to programmatic exception handling (as explained above) handles issues using the RequestProcessor class's processException() method and a Struts configuration file. To use declarative exception handling, you must do the following:

  1. Create custom application exception classes. You can design them so they hold more than one exception
  2. In the EJB/Web tier, trap application errors and wrap them into a custom exception class and throw them back
  3. In the struts-config.xml file, add the localized exception against an action-mapping or define a global exception (as shown below):

          input="input.jsp" >

Action chaining


A clear strategy for the relationship between JSP pages and Action classes in an application should be defined; i.e., how many JSP pages should be associated with an Action class.

For clarity and easy maintenance, the strategy for large applications should be to have one-to-one mapping between JSP pages and Action classes. With such a guideline in place, a prospective problem of duplicated code in the Action classes could result. To avoid logic duplication, you need some way to call an Action class's method from another Action class. Moreover for criss-cross page flow, you often need action chaining, or, to summarize, an implementation of the Chain of Responsibility design pattern.

Struts best practice

Possible solutions follow below:

  • Let ActionForwards point to a fresh request in the same application to invoke the method of another Action class.
  • RequestProcessor maintains a HashMap that stores all the instances of Action classes for that module. Extend the RequestProcessor class and provide getter methods for this HashMap. Provide a utility method in the application's parent Action class, which can invoke the methods of other Action classes within the same module. This utility method will use the Reflection API to achieve this.

The second approach is the best practice for large applications because if some change is required in exception handling, no code change will be required.


Large applications built using the above recommendations have been benchmarked for excellent performance.

As indicated by the Struts roadmap (featured on the Struts Website), features and extensions developed on and those commonly used by the Struts community are candidates for inclusion into Struts per se. All these are worth reading about before you make critical decisions about your application.

Puneet Agarwal works as a technical architect in the open architecture lab of Tata Consultancy Services Limited (TCS). In his six-year software career with TCS, he has designed technical architectures for various large- and medium-sized J2EE-based applications. Agarwal is an engineering graduate from the National Institute of Technology in Trichy, India.

Learn more about this topic

Join the discussion
Be the first to comment on this article. Our Commenting Policies