Top Most Struts 2.0 Introduction and Validations using Annotations

1) Introduction

This article provides an introduction to Struts 2.0 and its new Validation Features. Since Struts 2.0 is new, the first few sections of the article discusses in brief about the basics of Struts 2.0, its architecture and its various New Features. The rest of the article is dedicated towards explaining about the new Validation Features available. Struts is an Open-Source Web Application Framework that simplifies the creation of a Java Web Application. It is based on the Model-View-Controller 2 (MVC 2) Architecture which was originally found in a language called SmallTalk. The recent version of Struts is Struts 2.0 and it has borrowed most of the concepts in terms of architecture and functionality from two frameworks namely WebWorkand XWork.

2) Struts 2.0 - MVC Architecture

Struts 2.0 is based on MVC 2 Architecture. MVC is mainly concentrated in splitting the whole set of logic that happens in an Application into three different layers namely the Model, View and the Controller. In Struts 2.0, the Controller acts as a mediator between the View and the Model components. Whenever a request comes from a client, it is this Controller component who intercepts the request before being passed to Appropriate Handler.
Model represents the application data as well as the business logic that operates on the Data. Whenever the Framework routes the request to some Action class, the ActionClass will do the Business Processing Logic which results in the State of the Application getting affected. After the application's state is affected, the control is returned back to the Controller which determines which View to be Rendered to the Client Application.
View is the Display Surface given as a response back to the Client populated with values. Struts 2.0 is not restricted in having JSP as its only View. Any View Technolgy can be chosen to render the Client Surface. It can be JSP, Velocity, Freemaker, or even XSLT. Even a brand new View technology can be plugged-in easily to the Struts Framework.

3) The Flow of a Struts 2.0 Application

The following are the sequence of steps that will happen when a Html Client makes a request to a Web Application built on top of Struts 2.0

• The Client (which is usually a Html Browser) makes a Request to the Web Application.
• The Web Server will search for the Configuration Information that is very specific to the Web Application (taken from the web.xml file), and will identity which Boot-strap Component has to be loaded to serve the Client's Request.
• In Struts 2.0, this Component is going to be a Servlet Filter (whereas in Struts 1.0, the component is an Action Servlet).
• The Filter Servlet then finds out the Action Class for this Request that is mapped in the Configuration File. File.
• Before passing the Request to the Action class, the Controller passes the Request to a series of Interceptor Stack (explained later).
• Then the Request Object is passed on to the corresponding Action Class.
• The Action Class then executes the Appropriate Business Logic based on the Request and the Request Parameters.
• After the execution of the Business Logic, a Result ("success" or "error") is returned either in the form of String or in the form of Result Object back to the Controller.
• The Controller uses the Return Result to choose which View to be rendered back to the Client Application.

Let us look into the details of the major steps that was listed above.

3.1) Filter Servlet Loaded and Invoked by the Framework

A client makes a Web Request by typing the URL of the Web Application that is hosted in the Web Server something like the following, where localhost is the Machine Name where the Web Server is running, 8080 is the Port Number and hello is the Application Context for the Web Application.

http://localhost:8080/hello

Whenever a Request comes to a Web Application that is Struts 2.0 Enabled, the Web Server will search and load the Configuration Related Information that is very specific to the Application. In the case of a Struts 2.0 enabled Application, the Boot-Strap Component is going to a Filter Servlet. The Configuration Information about the Web Application will be maintained separately in web.xml file. Following is the Xml snippet taken from the web.xml file,
web.xml

<filter>

    <filter-name>Struts2FilterServlet</filter-name>

    <filter-class>

        org.apache.struts.action2.dispatcher.FilterDispatcher

    </filter-class>

</filter>

<filter-mapping>

    <filter-name>Struts2FilterServlet</filter-name>

    <url-pattern>/*</url-pattern>

</filter-mapping>

The above Xml Code tells that whatever be the Request URI Pattern (which is indicated by /*) that comes from the Client, identify the Component named by Struts2FilterServletwhich happens to be the class org.apache.struts.action2.dispatcher.FilterDispatcher. The Identified Component is then instantiated and then passed with the Request Information.

3.2) Request Intercepted by Interceptors

Interceptors provide Pre-processingand Post-processing functionality for a Request or a Response object in a Web Application. For general information about Interceptors, readers can go through thissection on JavaBeat. A Request Object usually passes through a Series of Interceptors before actually reaching the Framework. Assume that some kind of Authentication and Authorization related stuffs have to be done before a Request Object is being passed to a particular Module. In such a case, we can have the Core Business Logic that does the functionality of authorizing the Client Request in an Interceptor called AuthenticationInterceptor which does the Pre-processing works. Implementing a Custom Interceptor like this is very simple in Struts 2.0. The class structure may look like this,
AuthenticationInterceptor.java

package myinterceptors;

import com.opensymphony.xwork2.interceptor.*;

class AuthenticationInterceptor implements Interceptor{

    public void init(){}

    public void destroy(){}

    public String intercept(ActionInvocation invocation) throws Exception{

           // Get the value of user credentials from the Request and Validate it.

    }

}

As we can see, writing a Custom Interceptor is as simple as writing a class that implements the Interceptor interface which is found in the com.opensymphony.xwork2.interceptor package. The method of interest is Interceptor.intercept() which has to be overriden along with the the appropriate business logic. Then the Custom Interceptor has to be made available to the framework by adding information in the Configuration File (struts.xml) as shown below,
struts.xml

<struts>

    ... 

    <interceptors>

        <interceptor name = "authentication" 

            class = "myinterceptors.AuthenticationInterceptor">             

        </interceptor>

    <interceptors>

   ...  

</struts>

Interceptors are configured into the Web Application in the struts.xml file with the help of <interceptors> and <interceptor> entries. The nameattribute is the alias name of the interceptor and it must be unique among the other set of Interceptor names. The class attribute identifies the actual implementation class for an Interceptor. The advantages of interceptors is not only limited to this. Interceptors can participate in so many different activities, to name a few - providing Logging Information to an Application, providing Encryption Facilities for the user input that used to get transmitted across layers, etc.. . Struts 2.0 already comes with a bunch of Built-in Useful Interceptors.

3.3) Performing some Action for a Request

After passing through a series of Interceptors, now it is time for the Framework to determine what Action has to be done for the Request. The Mapping between a Request and its Corresponding Action is configurable in the Xml Configuration File. Assume that in a Web Application, Regitration, Login and Logout represents the different set of actions. Let us have an assumptions that the operations are fairly complex, so that we tend to have individual classes for each of the operation. These things are configured in the struts.xml like the following,
struts.xml

<struts>

    <action name = "Registration" class = "hello.RegistrationAction">

    <action name = "Login" class = "hello.LoginAction">

    <action name = "Logout" class = "hello.LogoutAction">

</struts>

The Action Class usually acts as a Model and executes a particular business logic depending on the Request object and the Input Parameters. In earlier versions of Struts (before Struts 2.0), an Action class is supposed to extend the org.apache.struts.Action class and has to override the Action.execute() method which takes four parameters. Following is the code snippet of an Action class before Struts 2.0,

MyAction.java

package myactions;

import java.servlet.http.*;

import org.apache.struts.*;

class MyAction extends Action{

    public ActionForward execute(ActionMapping mapping, ActionForm form,

        HttpServletRequest request, HttpServletResponse response)

        throws java.lang.Exception {

            // Do some business logic here.

        }

}

In Struts 2.0, an Action class is made flexible as it can be a simple POJO Class. It means that the Action Class doesn't need to extend some class or implement an interface. It can be as simple as possible, and the following code snippet proves the same,
MyAction.java

package myactions;

import com.opensymphony.xwork2.*;

class MyAction extends Action{

    public String execute(){

        // Some logic here.             

    }

}

Here comes the big question!. Then how can an Actionclass is supposed to access the HttpServletRequest and the HttpServletResponse objects to get the needed information!!! At this stage it is worth to mention about the Aware-Related Interfaces here. Suppose that an Actionclass wants to access the HttpServletRequest object. For this, it has to implement a special Aware Interface called ServletRequestAware and has to override the method setServletRequest(HttpServletRequest request)thereby storing it in an instance variable. So, the new modified action class becomes like this,
MyAction.java

package myactions;

import javax.servlet.http.*;

import com.opensymphony.xwork2.*;

import org.apache.struts2.interceptor.*;

class MyAction extends Action implements ServletRequestAware{

    private HttpServletRequest request;

    public String execute(){

    }

    public void setServletRequest(HttpServletRequest request){

        this.request = request;

    }

}

This above technique is basically an Inversion of Control. Inversion of Control is generally a Push Model which means that the data needed by the Application will be pushed by the Container or the Framework. In our case, we are making the Struts 2.0 Framework to call the method ServletRequestAware.setServletRequest(HttpServletRequest request)thereby populating the Request Object. Similar to this, there are Aware-Related Interfaces for Application, Servlet Request, Servlet Response, Parameters etc namely ApplicationAware, HttpServletRequestAware, HttpServletResponseAware, ParameterAware respectively.

3.4) Rendering the Result back to the Client

As we can see from the method signature, the return type of the Action.excute() method is just a String. This return type defines the Logical Outcome of the Action or the Page. Actual Outcome or the Response of a Page is configurable in the Struts Configuration File. Say the Action class can return a logical 'success' which tells that the action has be successfully processed or 'failure' which sadly tells that some thing wrong has happened in the Application. Some Predefined Constants have been defined in the Action interface for the logical outcomes namely, Action.SUCCESS, Action.ERROR, Action.LOGIN, Action.INPUT and Action.NONE. Consider the following code snippet,
MyAction.java

package myactions;

public class MyAction{

    public String execute(){

        if (createOperation()){

            return "create";

        }else if (deleteOperation()){

            return "delete";

        }else if( readOperation()){

            return "read";

        }else if  (writeOperation()){

            return "write";

        }

        return "error";

    }

}

The above method returns a bunch of Logical Outputs namely "create", "delete", "read" and "write". The logical outcomes should have their Corresponding Mappingsdefined in the struts.xml like the following,
struts.xml

<struts>

    …

    <action name = "MyAction" class = "myactions.MyAction">

        <result name = "create">/myApp/create.jsp</result>

        <result name = "delete">/myApp/delete.jsp</result>

        <result name = "read">/myApp/read.jsp</result>

        <result name = "write">/myApp/write.jsp</result>

    </action>

    …

</struts>

4) Struts.xml Configuration File

All the Configuration Related Information are externalized from a Web Application by maintaining them in a Xml File. The new Struts 2.0 Configuration Xml File is very Simple and Modular when compared with its older versions. Let us look into the structure of the Struts 2.0 Configuration File and the Core Elements within them in detail in the following sections.

4.1) Modularization of Configuration Files

The first nice feature is the File Inclusion Faciltity. Assume that in a very complex Web Application, there are multiple modules and each module is designated to be developed by a particular team. Similar to the Modularization of Work, the configuration file can also be made modular using the File Inclusion Facility. For the sake of simplicity, let the assume that there are three modules namely "admin", "customer", "employer" in a Web Application. We can define the three modules in three different Configuration Files, and using the File Inclusion Facility, the three files can be directly included in the Main Configuration File. A Main Configuration File is nothing but a File that includes other Configuration Files. Examine the following code snippet,
Admin-Config.xml

<struts>

    <!-- Configuration Information Related to Admin Module -->

</struts>

Customer-Config.xml

<struts>

    <!-- Configuration Information Related to Customer Module -->

</struts>

Employee-Config.xml

<struts>

    <!-- Configuration Information Related to Employee Module -->

</struts>

All the above separate Configuration Files can be directly referenced or included in the Root Configuration File with the help of <include> tag like the following,
Struts.xml

<struts>

    <!-- Other information goes here -->       

    <include file = "Admin-Config.xml"/>

    <include file = "Customer-Config.xml"/>

    <include file = "Employer-Config.xml"/>   

    <!-- Other information goes here -->

</struts>

4.2) Grouping of Similar Actions inside a Package

Packages in Java are logically used to group similar Classes or Interfaces. Similary, there is a <package> tag in Struts 2.0, which is used to Group Similar Actions along with Interceptors, Results, Exceptions etc. Following is the structure of the packageelement,
Struts.xml

<struts>

    <package name = "MyPackage1">

        <interceptors>

        </interceptors>

        <global-results>

        <global-results>

        <action name = "MyAction1">

        </action>

        <action name = "MyAction2">

        </action>

    </package>

    <package name = "MyPackage2">

        <interceptors>

        </interceptors>

        <global-results>

            <result name = "common-error">

                /myApp/commons/commonError.jsp

            </result>

        <global-results>

        <action name = "MyAction3">

            <result name = "result1">

                /myApp/myResult1.jsp

            </result>

        </action>

        <action name = "MyAction4">

        </action>

    </package>

</stuts>

Assuming that MyAction1 and MyAction2 are someway related, they are grouped under a package called MyPackage1. All the declaration of Interceptors, Results and Exceptionswithin the Package MyPackage1 will be availabe only within the actions MyAction1 and MyAction2. Similarly all the definition of the Interceptors, Results and Exceptions within the package MyPackage2will be applicable only for MyAction3 and MyAction4action elements. Packages can also be extended through the means of extends attribute like the following,
Struts.xml

<struts>

    ...

    <package name = "MySubPackage" extends = "MyBasePackage">

        ...                    

    </package>

    ...

</struts>

Let us define what a Package Extension is and their advantages. Assume that there is a Package called P1 with interceptors I1and I2, Results R1 and R2 and ExceptionsE1 and E2. If we say some Package called P2extends P1, then all the elements that are available in P1becomes visible to Package P2. Package Extension is very similar to Class Inheritance which we normally see in any kind of Object Oriented Language.

4.3) Interceptors and Stack

As previously discussed, Custom Interceptors can be written and made immediately available in Application by configuring them in the Configuration File with the help of <interceptor> tag. An Interceptor defined can be applied to a particlur Action (or a set of Actions) through the help of <intercept-ref> tag. Following Xml snippet will show this,
Struts.xml

<struts>

    <package name = "MyPackage">

        <interceptors>

            <interceptor name="logger-interceptor"

                class="myinterceptors.LoggingInterceptor">           

        </interceptor>

        <action name = "MyAction">

            <result name = "MyResult">

                /myApp/Result1.jsp

            </result>

            <interceptor-ref name = "logger-interceptor"/>

        </action>

    </package>

</struts>

The above code defines an Interceptor called logger-interceptor identified by the class myinterceptors.LoggingInterceptor and the same is included for an action called MyAction with the help of <interceptor-ref>tag. It is very common that a Set of Interceptors (often called Interceptor Stack) to be applied as a whole for one or more actions. Such a piece of functionality can be easily achieved with the help of <interceptor-stack>element.
struts.xml

<struts>

    <package name = "MyPackage">

        <interceptors>

            <!--Some set of common interceptors for a particular action-->

            <interceptor name = "A_I1" class = "MyA_I1">

            <interceptor name = "A_I2" class = "MyA_I2">

            <interceptor name = "A_I3" class = "MyA_I3">

            <interceptor name = "A_I4" class = "MyA_I4">

            <!--Another set of common interceptors  -->

            <interceptor name = "B_I1" class = "MyB_I1">

            <interceptor name = "B_I2" class = "MyB_I2">

            <interceptor name = "B_I3" class = "MyB_I3">

            <interceptor name = "B_I4" class = "MyB_I4">

        </interceptors>

        <interceptor-stack name = "A">

            <interceptor-ref name = "A_I1">

            <interceptor-ref name = "A_I2">

            <interceptor-ref name = "A_I3">

            <interceptor-ref name = "A_I4">

        </interceptor-stack>

        <interceptor-stack name = "B">

            <interceptor-ref name = "B_I1">

            <interceptor-ref name = "B_I2">

            <interceptor-ref name = "B_I3">

            <interceptor-ref name = "B_I4">

        </interceptor-stack>

        <action name = "MyAction1">

            <interceptor-ref name = "A"/>

        </action>

        <action name = "MyAction2">

            <interceptor-ref name = "B"/>

        </action>

        </package>

</struts>

The above Xml snippet defines a series of interceptors with the help of <interceptors>tag. Related Set of Interceptors to be added to an action element is then categorized with the help of <interceptor-stack>element. The categorized Interceptor Stack is then bound to an action element using the same sensible <interceptor-ref> tag. The framework is sensible here, it will find out the value for the nameattribute. If the value is an interceptor name, then the corresponding intercept() method will be invoked, else if the value is an Interceptor-Stack, then all the interceptors within the stack are iterated in the same order as their definition and their intercept()method will be invoked.

5) Validation using Configuration Files and Annotations

Struts 2.0 comes with new set of Robust Validation Features. Most of the common Validation Activities related to a Web Application are taken care by the Framework itself which means that only less burden lies on the shoulders of a Developer. Following lists the most commonly used Validations in Struts 2.0,

1. Integer Validation - Checks whether the value for a field is an integer and it falls within the integer range.
2. Double Validation - Checks whether the value for a field is a double and it falls within the double range.
3. Date Validation - Checks whether the value of the field is a Date value.
4. Email Validation - Validates whether the input string is in appropriate email format (Eg: userName@someDomain.com).
5. Url Validation - Ensures whether the value for a field is in appropriate URL Format.
6. Required Validation - Checks for the emptiness of a field value.
7. Required String Validation - Checks for the emptiness of a trimmed String value (not null)
8. String Length Validation - Checks whether the given field value is of the specified length.
9. Regex Validation - Ensures whether the field Value given matches the Regular Expression.

5.1) Validations Types based on Scope

Validation comes in two different flavors based on its Scope. A Scope defines whether a Validation is dedicated to a Single Field in a Page or it corresponds to a particular Action which may involve more than one fields along with some other constraints. Based on this, the following types are available.

• Field Validation
• Non-Field Validation

5.1.1) Field Validation

Validating a Field in a Page for correctness is a common situation for almost any Web Application. As mentioned this type of Validation is restricted to a particular field. Common cases may be validating the username and password field for emptiness. Both Xml-Based Validation or Annotation-Based Validation can be mentioned for the field elements. The following snippet code is an example of Field-Level Validation.
validation.xml

<field name="username">

    <field-validator type="required">

        <message>User name cannot be empty.</message>

    </field-validator>

<field-name="username">

<field name="email_address">

    <field-validator type="required">

        <message>Email Address cannot be empty.</message>

    </field-validator>

    <field-validator type="email">

        <message>

            Enter the email id in proper format (eg: abc.def@xyz.com)

        </message>

    </field-validator>

</field>

The above Xml snippet essentially applies one Validation Rule to the username field and two Validation Rules to the email-address field. The type of the validation rule is specified by the attribute called type. In our case, the types represent the Required Validation (required)and the EMail Validation (email). Any number of validation rules can be attached to a field element with the help of <field-validator>tag.
Annotation-Based Validationfor a field is also possible. The only requirement for the class is that the class that contains the fields representing the page (it can be an Action class too) must be marked with the @Validation annotation. Assume the Validation has to take place when the user submits the form. It is known that the Action.execute() method will be invoked as a result of this. So we can perform the field validations by marking the necessary Annotations against the method.
MyAction.java

package myactions;

import com.opensymphony.xwork2.validator.annotations.*;

@Validation

public class MyAction{

    @Validations(

        emails = {              

        @EmailValidator(type = ValidatorType.SIMPLE, 

        fieldName = "email_address", 

        message = "Enter the email id in proper format (eg: abc.def@xyz.com)")

        } 

        requiredFields = {

        @RequiredFieldValidator(type = ValidatorType.SIMPLE, 

        fieldName = "email_address", 

        message = "Email Address cannot be empty.")},

        @RequiredFieldValidator(type = ValidatorType.SIMPLE, 

        fieldName = "username", 

        message = "User name cannot be empty.")}             

        }              

    )

    public String execute(){

        // Other Logic goes here..  

    }

}

Instead of marking the whole Bunch of Validations on the Action.execute method(), there is another alternate way wherein which the Annotation-Based Validation can be applied on a Field-by-Field basis. Assume that username and password are the two properties inside the Action class, then the following type of Annotation is also possible.
MyAction.java

package myactions;

import com.opensymphony.xwork2.validator.annotations.*;

public class MyAction{

    private String username;

    private String emailAddress;

    @RequiredFieldValidator(type = ValidatorType.SIMPLE, 

        fieldName = "username", 

        message = "User name cannot be empty.")      

    public String getUsername(){

        return username;

    }

    ...

    @RequiredFieldValidator(type = ValidatorType.SIMPLE, 

        fieldName = "email_address", 

        message = "Email Address cannot be empty.")  

    @EmailValidator(type = ValidatorType.SIMPLE, 

        fieldName = "email_address", 

        message = "Enter the email id in app. format(eg: abc.def@xyz.com)") 

    public String getEmailAddress(){

        return emailAddress;

    }   

}

5.1.2) Non-Field Validation

Non-Field Validationsare generally Application specific and they will be given implementation by the Application Developers. Example may be performing validations based one or more fields in a form along with some Application specific Business Logic. The only availabe Validation that comes along with Struts 2.0 in this category is the Expression Validation. Assume that in some Application an Employee is asked to enter his Dirth of Birth and the Joining Date. For sure, the Birth Date will be logically lesser than the Joining Date. We can enforce this kind of Validation Rule using Expression Validationas follows.
validation.xml

<field name = "date_of_birth">

</field>

<field name = "joining_date">     

</field>

<validator type = "expression">

    <param name="expression">

        date_of_birth lt joining_date

    </param>

    <message>

        Warning: DOB(${date_of_birth}) is greater than Joining Date(${joining_date})

    </message>

</validator>

The first noticeable thing in the above Xml snippet is that the type of the Validation is identified as expression. The param tag is used to specify the constraint to be applied for the Validation. Here the constraint is very simple which tells that the Date of Birth for an Employee must be lesser that his Joining Date in the Organisation. Also notice, how actually the value of the field is taken to display error messages ($field_name). If the user enters 10/10/2000 for the DOB field and 10/10/1960 in the Joining Date Field, then the message "Warning: DOB(10/10/2000) is greater than the Joining Date(10/10/1960)" will be flashed in the User Browser.

5.2) Validation Types based on Implementation

If we look at another angle based on how Validations are Configured or Implemented, they can be classified into two categories namely,

• Declarative Validation
• Programmtic Validation.

5.2.1) Declarative Validation

If the Validation Logic for a particular Field or for an Entire Action is specified either in the Xml File or through Annotations, then it is called Declarative Validation. Whatever Validation we are seeing till now are Declarative Validations only. The idea behind Declarative Validation is that during the Deployment time of the Web Application itself, the Framework or the Container will be in a suitable position to mapthe set of fields participating in Validations against their Validation Rules.

5.2.2) Programmatic Validation

Not at all times, the Built-in Validations provided by the Framework will be sufficient. At times, there will be a situation to perform a Complex Validation Logic that is very specific to an application. For example situation may occur wherein, a single value of a field can be validated based on the content of some other text-fields along with some values fetched from the Database. In such a case, we can implement the Validation Logic directly into the Code. The following code snippet shows that,
MyAction.java

package myactions;

import com.opensymphony.xwork2.*;

public class MyAction extends ActionSupport{

    public void validate(){    

        String stockSymbol = getStockFieldValue();

        if ((stockSymbol == null) || (stockSymbol.trim().length == 0) ){

            addFieldError("stock_field", "Stock Symbol cannot be empty"); 

        }

        boolean result = validateStockSymbolFromDb(stockSymbol);

        if (!result){

            addActionError("Invalid Stock Symbol");

        }

        // Other Code goes here.

    }

}

If an Application is going to provide Manual Validation, then it has to implement two interfaces namely Validateable and ValidationAware interfaces in the com.opensymphony.xwork2 package. The core logic for the Custom Validation must be done within the Validateable.validate() method. ValidationAware Interface is used to collect the Error Messagesthat are related to fields or to a general Action. Fortunately, as expected, Struts 2.0 provides Default Implementation for both these interfaces in the ActionSupport class. So it is wise to extend this class for performing any Validation Logic without redefining every methods available in the Validation Interfaces.
Our sample Action class extends ActionSupport class to get all the Basic functionality for Storing and Retrieving Error Messages. Two types of Error Messages are available in the ValidationAware interface. One is the Field-level Messages and the other thing is the Action-Level Messages. Convinient methods are available for populating and retreiving both these messages. Methods addActionError(String message)and addFieldMessage(String fieldName, String message) are used to populate the error messages to an internal Collection. To retrive the Error Messages getActionErrors() and getFieldErrors() are used. To check whether errors have occured in a page use hasActionErrors() and hasFieldErrors() methods.
The sample code essentially checks the value of the stock symbol obtained from the field and checks for its emptiness. If not, it is populating the field-level error message by calling the addFieldMessage("..."). It then make Database Calls to ensure whether the Stock Symbol is valid. If not, an Action Level Error message is populated in the code by calling addActionEror("...");