Custom Validators in Struts 2.0

Introduction

Struts 2.0 is the popular Open Source Presentation Tier framework developed by Apache Group. It is based on MVC Model 2 design pattern. Dispatcher Filter is the front controller for the struts2 based applications. Struts 2.0 has simplified web development for its users by introducing POJO based actions, interceptors, flexible validation and support for many different result types. Struts can be used to build the user interface tier of the enterprise application. Data validation is an important aspect in enterprise applications. This article explains the concept of custom validators.

Development Environment

• NetBeans IDE 6.9
• GlassFish V3

Project Structure

The sample application developed in this article is ‘Struts2CustomValidation’
where a user can register to the application by specifying few details like userId,firstname,city etc. Custom validator developed in the application will be responsible for validating the value of the city field.

Libraries/Jar Files Required

• Struts 2.0 jar files

The complete application structure is shown below:

• The User Interface (JSP pages) is created in the “Web Pages” directory. The java classes (Actions, Interceptors and struts.xml) are created in the “Source Packages” directory. The required jar files are present in the “Libraries” directory. The web application deployment descriptor “web.xml” is created by the IDE in the “WEB-INF” subdirectory of “Web Pages”.

Action Class

Struts does the request processing with the help of Action classes. Here’s the code for the RegisterAction.java which handles the
request to register to our application. This class is created in the package “com.actions”.

RegisterAction.java

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66

package com.actions;
	import com.opensymphony.xwork2.ActionSupport;
	import java.util.Date;
	public class RegisterAction extends ActionSupport {
		private String userId;
		private String firstName;
		private String lastName;
		private int age;
		private String city;
		private String email;
		private Date joiningDate;
		private String password;
		public String getPassword() {
			return password;
		}
		public void setPassword(String password) {
			this.password = password;
		}
		public String getUserId() {
			return userId;
		}
		public void setUserId(String userId) {
			this.userId = userId;
		}
		public Date getJoiningDate() {
			return joiningDate;
		}
		public void setJoiningDate(Date joiningDate) {	
			this.joiningDate = joiningDate;
		}
		public int getAge() {
			return age;
		}
		public void setAge(int age) {
			this.age = age;
		}
		public String getCity() {
			return city;
		}
		public void setCity(String city) {
			this.city = city;
		}
		public String getEmail() {
			return email;
		}
		public void setEmail(String email) {
			this.email = email;
		}
		public String getFirstName() {
			return firstName;
		}
		public void setFirstName(String firstName) {
			this.firstName = firstName;
		}
		public String getLastName() {
			return lastName;
		}
		public void setLastName(String lastName) {
			this.lastName = lastName;
		}
 
		@Override
		public String execute() {
			return "success";
		}
	}

Let us understand the request processing logic in the action class. The action class handles the register request in the execute method. There’s no validation logic hardcoded in the java class. The complete validation logic including the custom validation is added in the “RegisterAction-validation.xml” file.Upon successful validation, the user is forwarded to “Register_Success.jsp” page.

We have put the validation logic in the “RegisterAction-validation.xml” file kept in the “com.actions” package. Please note that the validation.xml file should always be kept in the same package where your action class is present.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97

<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE validators PUBLIC
		"-//OpenSymphony Group//XWork Validator 1.0.2//EN"
		"http://www.opensymphony.com/xwork/xwork-validator-1.0.2.dtd">
	<validators>
		<field name="userId">
			<field-validator type="requiredstring">
				<message>Employee Id is a mandatory field</message>
			</field-validator>
			<field-validator type="regex">
				<param name="expression">
					<![CDATA[([E][m][p][0-9][0-9][0-9])]]>
				</param>
				<message>Valid Employee Id required e.g. Emp001</message>
			</field-validator>
		</field>
		<field name="age">
			<field-validator type="int">
				<param name="min">20</param>
				<param name="max">80</param>
				<message>Age needs to between ${min} and ${max}</message>
			</field-validator>
		</field>
		<field name="firstName">
			<field-validator type="requiredstring">
				<param name="trim">true</param>
				<message>First Name is required</message>
			</field-validator>
			<field-validator type="stringlength">
				<param name="maxLength">10</param>
				<param name="minLength">5</param>
				<param name="trim">true</param>
				<message>
					Enter firstName between 5 and 10 characters
				</message>
			</field-validator>
		</field>
		<field name="lastName">
			<field-validator type="requiredstring">
				<param name="trim">true</param>
				<message>Last Name is required</message>
			</field-validator>
			<field-validator type="stringlength">
				<param name="maxLength">10</param>
				<param name="minLength">5</param>
				<param name="trim">true</param>
				<message>
					Enter lastName between 5 and 10 characters
				</message>
			</field-validator>
		</field>
		<field name="password">
			<field-validator type="requiredstring">
				<message>Password is required</message>
			</field-validator>
			<field-validator type="stringlength">
				<param name="maxLength">10</param>
				<param name="minLength">5</param>
				<param name="trim">true</param>
				<message>
					Enter password between 5 and 10 characters
				</message>
			</field-validator>
		</field>
		<field name="city">
			<field-validator type="requiredstring" short-circuit="true">
				<param name="trim">true</param>
				<message>You can not leave city as blank</message>
			</field-validator>
			<field-validator type="cityValidator" short-circuit="true">
				<message>City value is incorrect. it must match the pattern Az*</message>
			</field-validator>
		</field>
		<field name="email">
			<field-validator type="requiredstring">
				<param name="trim">true</param>
				<message>You can not leave email as blank</message>
			</field-validator>
			<field-validator type="email">
				<message>
					The email address you entered is not valid.
				</message>
			</field-validator>
		</field>
		<field name="joiningDate">
			<field-validator type="required">
				<message>
					You cannot leave the date of joining field blank.
				</message>
			</field-validator>
			<field-validator type="date" >
				<message>
					Joining date must be supplied
				</message>
			</field-validator>
		</field>
	</validators>

The data validation is performed with the help of “RegisterAction-validation.xml” file. Different validation routines are configured for the the various attributes.Along with the various built in validations, we have made use of a custom validator “cityValidator” to validate the value of the “city” attribute. The id of the validator “cityValidator” is taken from the file validators.xml which is created in the default class path.

• The User Interface (JSP pages) is created in the “Web Pages” directory. The java classes (Actions, Interceptors and struts.xml) are created in the “Source Packages” directory. The required jar files are present in the “Libraries” directory. The web application deployment descriptor “web.xml” is created by the IDE in the “WEB-INF” subdirectory of “Web Pages”.

Action Class

Struts does the request processing with the help of Action classes. Here’s the code for the LoginAction.java which handles the
request to login to our application. This class is created in the package “demo”.

LoginAction.java

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

package demo;
 
	import com.opensymphony.xwork2.ActionSupport;
	import com.opensymphony.xwork2.ActionContext;
	import java.util.*;
 
	public class LoginAction extends ActionSupport {
	    private String userId;
	    private String password;
	    public String execute() throws Exception {
	        if ("admin".equals(userId) && "admin".equals(password)) {
	            Map session = ActionContext.getContext().getSession();
	            session.put("logged-in", "true");
	            return SUCCESS;
	        } else {
	            return ERROR;
	        }
	    }
 
	    public String logout() throws Exception {
 
	        Map session = ActionContext.getContext().getSession();
	        session.remove("logged-in");
	        return SUCCESS;
	    }
 
	    public String getPassword() {
	        return password;
	    }
 
	    public void setPassword(String password) {
	        this.password = password;
	    }
 
	    public String getUserId() {
	        return userId;
	    }
 
		public void setUserId(String userId) {
	        this.userId = userId;
	    }
	}

Let us understand the request processing in the action class. The action class handles the login request in the execute method, where we are validating that both the userId and password values must be “admin”. If the values do not match, then the user is forwarded to “Login_Failure.jsp” page. Upon successful validation, the user is forwarded to “Login_Success.jsp” page.Also, in the execute method we have added a sleep interval of 2 seconds, to show the time spent in the action class via interceptor.

Please note that there’s no validation logic in the action class. We have put the validation logic in the “LoginAction-validation.xml” file kept in the “demo” package. Please note that the validation.xml file should always be kept in the same package where your action class is
present.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE validators PUBLIC
		"-//OpenSymphony Group//XWork Validator 1.0.2//EN"
		"http://www.opensymphony.com/xwork/xwork-validator-1.0.2.dtd">
 
		<validators>
			<field name="userId">
				<field-validator type="requiredstring">
					<message>User Id is a mandatory field</message>
				</field-validator>
			</field>      
			<field name="password">
				<field-validator type="requiredstring">
					<message>Password is required</message>
				</field-validator>
			<field-validator type="stringlength">
				<param name="maxLength">10</param>
				<param name="minLength">5</param>
				<param name="trim">true</param>
				<message>
					Enter password between 5 and 10 characters
				</message>
			</field-validator>
		</field>
	</validators>

The data validation is performed with the help of “LoginAction-validation.xml” file. Different validation routines are configured for the both the attributes (userId and password).

The Custom Interceptor

In this application, we have created a custom interceptor “MyCustomInterceptor” which keeps track of the time spent in the action class. The interceptor is created in the interceptors package inside Source Packages sub directory.The custom interceptor provides the implementation of Interceptor interface and provides the implementation of init(),destory() and intercept() methods.

Here’s the code for the MyCustomInterceptor.java which handles the logic to calculate the time spent in the action. This class is created in the package “interceptors”.

MyCustomInterceptor.java

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

package interceptors;
 
	import com.opensymphony.xwork2.ActionInvocation;
	import com.opensymphony.xwork2.interceptor.Interceptor;
	import java.text.SimpleDateFormat;
	import java.util.Calendar;
	import java.util.Date;
 
	public class MyCustomInterceptor implements Interceptor {
		public String intercept(ActionInvocation next) throws Exception {
	        System.out.println("*****************************");
		    SimpleDateFormat sdf = new SimpleDateFormat(" MM/dd/yyyy HH:mm:ss ");
	        Calendar cal = Calendar.getInstance();
	        Date initDate = cal.getTime();
	        String newdate = sdf.format(initDate);
	        System.out.println("In the interceptor in pre processing logic");
	        System.out.println("Request reached the custom interceptor @ " + newdate + " time");
	        System.out.println("*****************************");
	        Thread.sleep(2000);
	        String s = next.invoke();
	        System.out.println("*****************************");
	        System.out.println("Back in the interceptor in post processing logic");
	        Calendar cal1 = Calendar.getInstance();
	        String finalDate = sdf.format(cal1.getTime());
	        System.out.println("Request returned in the custom interceptor @ " + finalDate + " time");
	        long milliseconds1 = cal.getTimeInMillis();
	        long milliseconds2 = cal1.getTimeInMillis();
	        long timeDiff = milliseconds2 - milliseconds1;
	        long timeDiffSeconds = timeDiff / 1000;
	        long timeDiffMinutes = timeDiff / (60 * 1000);
	        System.out.println("Time in milliseconds: " + timeDiff + " milliseconds.");
	        System.out.println("Time in seconds: " + timeDiffSeconds + " seconds.");
	        System.out.println("Time in minutes: " + timeDiffMinutes + " minutes.");
	        System.out.println("*****************************");
	        return s;
	    }
 
		public void init() {
	        System.out.println("Interceptor is initialized");
	    }
 
		public void destroy() {
	        System.out.println("In the destroy method of Interceptor");
	    }
	}

The User Interface Tier

The user interface part of the application is created in JSP. The home page of the application is “Login.jsp”, where a form is displayed to the users asking for userId and password for login purpose. PFB the code of “Login.jsp”

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

<%@ taglib prefix="s" uri="/struts-tags"%>
	<%@ page language="java" contentType="text/html"%>
 
	<html>
	<head>
		<title>Login Page!</title>
	</head>
	<body>
	    <s:form action="login.action" method="post">
			<s:textfield name="userId" label="Login Id" />
			<br>
			<s:password name="password" label="Password" />
			<br>
			<s:submit value="Login" align="center" />
		</s:form>
		<s:actionerror />
 
	</body>
	</html>

Once the user fills in the both userId and password & clicks on the “Submit” button, the request is submitted to the action class. Upon
successful validation, the user is forwarded to “Login_Success.jsp”page. Here’s the code of “Login_Success.jsp”.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

<%@ taglib prefix="s" uri="/struts-tags" %>
	<%@ page language="java" contentType="text/html" import="java.util.*"%>
 
	<html>
	<head>
		<title>Welcome, you have logged in!</title>
	</head>
	<body>
		Welcome, you have logged in. <br />
		<b>Session Time: </b><%=new Date(session.getLastAccessedTime())%>
		<br /><br />
		<a href="<%= request.getContextPath()%>/logout.action">Logout</a>
		<br />
	</body>
	</html>

In case, the userId and password values are invalid, the user is forwarded to Login_Failure.jspHere’s the code of “Login_Failure.jsp”.

1
2
3
4
5
6
7
8
9
10
11
12
13

<%@ page language="java" contentType="text/html; charset=ISO-8859-1"
         pageEncoding="ISO-8859-1"%>
	<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
	<html>
	<head>
		<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
		<title>Login Failure</title>
	</head>
	<body>
		Invalid Username/Password. Please Retry!!!!
		<a href="Login.jsp">Logout</a>
	</body>
	</html>

The Configuration Files

Here’s the configuration added in the “web.xml” file:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

<?xml version="1.0" encoding="UTF-8"?>
	<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"	xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
		<filter>
			<filter-name>struts2</filter-name>
			<filter-class>org.apache.struts2.dispatcher.FilterDispatcher</filter-class>
		</filter>
		<filter-mapping>
			<filter-name>struts2</filter-name>
			<url-pattern>/*</url-pattern>
		</filter-mapping>
		<session-config>
			<session-timeout>
				30
			</session-timeout>
		</session-config>
		<welcome-file-list>
			<welcome-file>Login.jsp</welcome-file>
		</welcome-file-list>
	</web-app>

In the deployment descriptor, we have added the following configurations:

1. The Welcome File of the application
2. Struts2 Dispatcher Filter (Controller element of Struts2
   applications)

Here’s the configuration added in the “struts.xml” file kept in the default package in the “Source Packages” directory.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

<?xml version="1.0" encoding="UTF-8" ?>
	<!DOCTYPE struts PUBLIC
		"-//Apache Software Foundation//DTD Struts Configuration 2.0//EN" "http://struts.apache.org/dtds/struts-2.0.dtd">
	<struts>
		<constant name="struts.devMode" value="false"/>
		<package name="default" extends="struts-default" namespace="/">
			<interceptors>
				<interceptor name="customtimer" class="interceptors.MyCustomInterceptor"/>
				<interceptor-stack name="timerstack">
					<interceptor-ref name="defaultStack" />
					<interceptor-ref name="customtimer"/>
				</interceptor-stack>
			</interceptors>
 
			<default-interceptor-ref name="timerstack" />
			<action name="login" class="demo.LoginAction">
				<result name="success">/Login_Success.jsp</result>
				<result name="error">
					/Login_Failure.jsp
				</result>
 
				<result name="input">
					/Login.jsp
				</result>
			</action>
			<action name="logout" class="demo.LoginAction" method="logout">
				<result name="success" type="redirect">
					Login.jsp
				</result>
				<result name="input" type="redirect">/Login.jsp</result>
			</action>
		</package>
	</struts>

In the struts.xml, we have added the following configurations:

1. The custom interceptor is configured and given an alias “customtimer”
2. A custom stack of interceptors is created and given an alias “timerstack”. The same stack is also configured to be the default interceptor stack of the application.
3. “execute” method of “LoginAction” class is configured to handled the login attempt to the application.
4. “logout” method of “LoginAction” class is configured to handled the logout attempt from the application.

Executing The Application

Finally, we are ready to execute the application. Deploy the application to the container and execute.

Open the Login.jsp page.

Enter some invalid data, The snapshot given below shows the validation error messages

Once, all the validation error messages have been rectified, the user is forwarded to Login_Success.jsp page, where the welcome message is displayed.

Click on the “Logout” button and the user is redirected back to Login.jsp page.

Check the server console. It shows the messages from our custom timer interceptor. The time in the preprocessing and postprocessing is displayed along with the time spent in action method in milliseconds, seconds and minutes format.

Conclusion

Thus, any Struts application can take benefit of the built in interceptors and also take control of request processing by creating custom interceptors.

Struts 2.0 is the popular Open Source Presentation Tier framework developed by Apache Group. It is based on MVC Model 2 design pattern. Dispatcher Filter is the front controller for the struts2 based applications. Struts 2.0 has simplified web development for its users by introducing POJO based actions, interceptors, flexible validation and support for many different result types.

Struts can be used to build the user interface tier of the enterprise application. Whereas, any of the popular ORMs like Hibernate, JPA, iBatis can be used for the persistence tier of the application. Struts2 provides easy integration with these persistence tier frameworks.

This article demonstrates the integration of Struts 2.0 applications with the Java Persistence API (JPA). The concept is explained with the help of a sample application. Knowledge of JPA and Struts 2.0 is the prerequisite for this article.

Development Environment

• NetBeans IDE 6.8
• GlassFish V2.x
• Apache Derby Database

Project Structure

The sample application developed in this article is “StrutsJPADemo” where an employee details are persisted to the database with the help of JPA.

Libraries/Jar Files Required

• Struts 2.0 jar files
• JPA jar files
• Jar file for the database driver (derbyclient.jar, in our case) The
  complete application structure is shown below:
• 
• The User Interface (JSP pages) is created in the “Web Pages” directory. The java classes (Actions, Entities, Service classes, Resource Bundles, struts.xml) are created in the “Source Packages” directory. The required jar files are present in the “Libraries” directory. The web application deployment descriptor “web.xml” is created by the IDE in the “WEB-INF” subdirectory of “Web Pages”. This sample application stores the employee details into the Derby database.

Environment Set Up

Once the web application is created and all the required libraries are added to the classpath, we can start working on the different components of the application.

Before we start working on the different application components like JSP pages and Java classes, we must first configure the following resources in the application server:

1. javax.transaction.UserTransaction
   1. In our application, we have created a UserTransaction and bound the same in JNDI with the name “UserTransaction”. The snapshot given below shows the same.
   2. 

2. Connection Pool & DSN
   1. For the database, we have created a connection pool in the application server to connect to ScrambleDatabase in the local machine running at port number 1527. The connection pool is bound to the name
      “scramblePool” as shown in the snapshot below.

   

   1. The next step is to configure the DSN in the application server. Our DSN is bound to the name “jdbc/scramdleDSN” in JNDI. This is shown below in the snapshot. This DSN will use “scramblePool”created in the previous step.

   

The author asuumes readers of this article have basic knowledge of Struts 2.0 and Hibernate.If you are beginner in learning Struts and hibernate, please read Introduction to Struts 2.0 and Introduction to Hibernate. The sample is created in NetBens IDE. Sample project struture is displayed in the next section.

Project Structure

This application which is discussed here stores the registration details of an employee to an Oracle DB table using struts 2 and hibernate.Includ the hibernate jar files and struts 2.0 jar files to the project class path. Since we are using Oraccle we need to load the classes12.jar/odbc5.jar also to the class path.

Create the domain model Employee.java as below.This class will be used as the hibernate model object.Hence we need to have the hibernate mapping files created for this as listed in the next section.

The same is used to push the form data to the valuestack.ValueStack, as you know already , is ,one of the powerful features of Struts 2.ValueStack can be defined as a storage structure where the data associated with the current request is stored.

The properties of this bean is directly accessible from the JSP pages using OGNL expresion language.

Listing 1. Employee.java

public class Employee {
    private int empno;
    private String name;
    private String jobtitle;
    private String unit;//business unit  - Retail,Testing, etc
    private String technology;//current working technology
	// getter  & setter methods
}

Struts 2.0 Action Class Registration.java

As you are already aware of , Struts 2 do not have the ActionForm concept. But those of you ,who would like to use such a feature in Struts 2, they can create a POJO that holds the form data in its properties and then create an Action class that implements the ModelDriven interface. This is what we have done in the sample described here.

Please note that when you implement ModelDriven interface, you need to get the model object using the getModel() method. The Preparable interface is implemented here so that the action class can prepare itself. If you don’t have anything to prepare, there’s no reason to implement Preparable. Here we are initializing the instance of the Employee object with the prepare() method of the Preparable interface.

Listing 2 : Model Driven Action class – Registration.java

package com.myaction;

import com.opensymphony.xwork2.ActionSupport;
import com.opensymphony.xwork2.ModelDriven;
import com.opensymphony.xwork2.Preparable;
import org.hibernate.HibernateException;
import org.hibernate.Session;
import org.hibernate.SessionFactory;
import org.hibernate.Transaction;
import org.hibernate.cfg.Configuration;
public class Registration extends ActionSupport implements ModelDriven, Preparable {

    Employee employee;
    SessionFactory sessionFactory = null;
    Session session = null;

    public String execute() {
        try {
            sessionFactory = new Configuration().configure().buildSessionFactory();
            session = sessionFactory.openSession();
            Transaction transaction = session.beginTransaction();
            session.saveOrUpdate(employee);
            transaction .commit();
            System.out.println("Record Inserted Successfully");
        } catch (HibernateException hibernateException) {
            System.out.println(hibernateException.getMessage());
            session.close();
            return "ERROR";
        }
        return "SUCCESS";
    }

    @Override
    public Employee getModel() {
        return employee;
    }
    @Override
    public void prepare() throws Exception {
        employee = new Employee();
    }
}

In this action class we are obtaining the SessionFactory instance from the hibernate configuration. Once the SessionFactory instance is obtained, you can create the Session object and invoke the necessary methods for insertion / updation of the records in the table.

JSP Pages

We use three JSP pages in this application. The first one is the index.jsp page that accepts the registration details of the employee. Upon submiting this form, the action class’ execute method is invoked and data is strored in the database. Success.jsp(Listed next) will be shown to the user upon successful insertion of the data.

If an error occurs during insertion , Error.jsp is displayed.

Listing 3 :index.jsp

<%@page contentType="text/html" pageEncoding="UTF-8"%>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
    "http://www.w3.org/TR/html4/loose.dtd">
<%@taglib uri="/struts-tags"  prefix="s"%>
<html>
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
        <title>JSP Page</title>
    </head>
    <body>
        <center>
            <!-- <img src="PDT_TVM_SMall.JPG"/> -->
            <h1>Registration Form</h1>
            <s:form action="Registration">
                <table bgcolor="pink">
                    <tr>
                        <td>
                            <s:textfield name="empno" label=" Employee Id " value="" />
                        </td>
                        <td>
                            <s:textfield name="name" label=" Name" />
                        </td>
                        <td>
                            <s:textfield name="jobtitle" label=" Job Title " />
                        </td>
                        <td>
                            <s:combobox label=" Business Unit " name="unit"
                                        headerValue="--- Please Select ---"
                                        headerKey="1"
                                        list="{'Retail','HR','Quality','R&D','Testing','Facilities'}" />
                        </td>
                        <td>
                            <s:combobox label=" Current Technology Area" name="technology"
                                        headerValue="--- Please Select ---"
                                        headerKey="1"
                                        list="{'Java','J2EE','.NET','Main Frame','Others'}"/>
                        </td>
                        <td colspan="0"><s:submit label="Register"/></td>
                    </tr>
                </table>
            </s:form>
        </center>
    </body>
</html>

Listing 4 : Success.jsp

<%@page contentType="text/html" pageEncoding="UTF-8" import="com.myaction.Employee"%>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
   "http://www.w3.org/TR/html4/loose.dtd">
<%@taglib prefix="s"  uri="/struts-tags"%>
<html>
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
        <title>JSP Page</title>
    </head>
    <body><center>
            <br>  <br>  <br>  <br>
            <h1 style="color:chocolate"> <s:property value="name"/> registered successfully !!</h1>
               </center>
           </body>
</html>

Listing 5 : Error.jsp

<%@page contentType="text/html" pageEncoding="UTF-8" errorPage="Error.jsp"%>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
   "http://www.w3.org/TR/html4/loose.dtd">

<html>
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
        <title>Error Page</title>
    </head>
    <body>
        <h1>Some Error Occurred !!  </h1>
    </body>
</html>

Oracle Database table structure

Listing 6 : web.xml

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="3.0" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd">
    <filter>
        <filter-name>struts2</filter-name>
        <filter-class>org.apache.struts2.dispatcher.FilterDispatcher</filter-class>
    </filter>
    <filter-mapping>
        <filter-name>struts2</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>
    <session-config>
        <session-timeout>
            30
        </session-timeout>
    </session-config>
    <welcome-file-list>
        <welcome-file>index.jsp</welcome-file>
    </welcome-file-list>
</web-app>

Hibernate and Struts 2 configuration files

Listing 7 : Struts.xml

<!DOCTYPE struts PUBLIC
"-//Apache Software Foundation//DTD Struts Configuration 2.0//EN"
"http://struts.apache.org/dtds/struts-2.0.dtd">

<struts>
    <!-- Configuration for the default package. -->
     <package name="default" extends="struts-default">
        <action name="Registration" class="com.myaction.Registration">
            <result name="SUCCESS">/Success.jsp</result>
             <result name="ERROR">/Error.jsp</result>
        </action>
    </package>
</struts>

Listing 8 : hibernate.cfg.xml – Hibernate configuration file

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE hibernate-configuration PUBLIC "-//Hibernate/Hibernate Configuration DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">
<hibernate-configuration>
    <session-factory>
        <property name="hibernate.dialect">org.hibernate.dialect.Oracle8iDialect</property>
        <property name="hibernate.connection.driver_class">oracle.jdbc.OracleDriver</property>
        <property name="hibernate.connection.url">jdbc:oracle:thin:@10.154.117.76:1521:oracle</property>
        <property name="hibernate.connection.username">user</property>
        <property name="hibernate.connection.password">password</property>
        <property name="hibernate.hbm2ddl.auto">update</property>
        <property name="hibernate.show_sql">true</property>
        <mapping resource="Employee.hbm.xml"/>
    </session-factory>
</hibernate-configuration>

Listing 9 : Employee.hbm.xml – hibernate mapping file

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
<hibernate-mapping>
  <class name="com.myaction.Employee" table="StrutsHibEmployee">
    <id column="EMPNO" name="empno" type="int">
      <generator class="assigned"/>
    </id>
    <property column="EMPNAME" name="name" type="string"/>
    <property column="ROLE" name="jobtitle" type="string"/>
    <property column="UNIT" name="unit" type="string"/>
    <property column="TECHNOLOGY" name="technology" type="string"/>
  </class>
</hibernate-mapping>

Run the application. Sample screen shots are shown below.

Output can be verified in the database as below.

Summary

Integrating Struts 2.0 with Hibernate is very simple. From the sample explained in the article, you can see that there is no need of using any separate pluggins for this. What is required is to get the SessionFactory object in the Action class and use it the way you use it in normal Java Applications.

The most popular and the biggest user of AJAX is Google. Orkut, Gmail, the latest beta version of Google Groups, Google Suggest, and Google Maps — are Ajax applications Google mail, Google calendar and Google home page are some examples. In your Google mailbox the “loading” that is displayed in the top right corner is using these Ajax technologies. The new Yahoo homepage too uses some of these technologies. Another cool Ajax implemented website would be www.pageflakes.com Others are following suit: many of the features that people love in Flickr depend on Ajax, and Amazon’s A9.com search engine applies similar techniques.

The BackScreen of Ajax

In traditional webpages, the pages will be reloaded for each and every request. But in most of the cases only a part of the page will be processed. Hence such a page reload is unnecessary. Thus the usage of ajax plays a efficient role. In the webpages, that are using ajax, only the part of the page that has to be processed will be transferred to the web server and the processed data will be loaded in the page without a page reload.

AJAX internals

AJAX is not a single technology as mentioned earlier. It is important to remember that AJAX is not Java or .NET dependent.

Whatever be your back end code, you can use AJAX to communicate with it. People prefer AJAX for the high speed with which it works. It does it with three basic ways

• Better utilization of browser cache
• Batching up of network requests in a single packet to reduce network latency issues
• Decreasing the workload on the server by not requiring it to process the entire page

Where can we use AJAX

Forms:

Web based forms are slow. AJAX can definitely improve the performance of web-based formsUser Communication:

User communications like chat pages, voting’s and ratings can be done efficiently using AJAX

News:

RSS feed is another popular concept where AJAX can be used

Data Manipulation:

This includes some sort of filtering data, selecting names from one combo box to another, sorting data, invoking the suggest criteria or a hint

Defining Ajax

As we have seen an introduction to AJAX, let us try to define it. Ajax isn’t a technology. It’s really several technologies, each flourishing in its own right, coming together in powerful new ways. Ajax incorporates:

• Standards-based presentation using XHTML and CSS;
• Dynamic display and interaction using the Document Object Model;
• Data interchange and manipulation using XML and XSLT;
• Asynchronous data retrieval using XMLHttpRequest;

And JavaScript binding everything together.
So, how does AJAX does this sending request and getting response from the backend server??

Using the XML Http Request object.

XML Http Request object

The XML HttpRequest was introduced by Microsoft in Internet Explorer 5.0. Recently , Mozilla and apple have included support for this in their web browsers(Firefox and Safari).This object is the fundamental basis for Ajax. Microsoft implementation is different from that of other web browsers, so when you create this object in your code, you need to do a typical browser check.

For Internet Explorer, we can create this object using,

Var req = new ActiveXObject(“Microsoft.XMLHTTP”);

For firefox and safari,

Var req = new XMLHttpRequest();

Struts and Ajax in Action

As we have seen enough of the theory behind the working of Ajax in struts let us see an example. Simple example is loading a drop down depending on the selected item in another drop down. We need to populate the characters in a “showcharacters” dropdown when a particular TV Show is selected in the “showTVShow” drop down using AJAX. Let us see the Ajax request response cycle for this scenario.

Step 1: Create a jsp page (“tvshow.jsp”)

Let us take three TV shows which I like.”Lisse Maguire”,” That’s so Raven” and “Dhoom Machallo Dhoom”. We need to populate the characters dropdown as and when the TV Show dropdown value changes , so we decide to call the javascript in the “onchange()” of the select box.

<html:form action="showCharacters.do">
		TV Show:
		<html:select property="TVShowSelect"
						onchange="retrieveURL(' showCharacters.do?tvShow=' + this.value);">
			<html:option value="Lissie Maguire"> Lissie Maguire </html:option>
			<html:option value="That’s so Raven"> That’s so Raven </html:option>
			<html:option value="Dhoom machale"> Dhoom machale </html:option>
		</html:select>
		<br>
		Characters: <span id="characters"></span>
	</html:form>	

Here we are sending a URL to the Java script function.

“’ showCharacters.do?tvShow=' + this.value”

We are appending the selected item with the URL as a query string. We can also just send the Url and append the form contents in the java script.

Step:2 Making the AJAX Call to the Server

In the java script we need to create a XML HttpRequest object

	function retrieveURL(url)
	{
	if (window.XMLHttpRequest)
	{
	// Non-IE browsers
				req = new XMLHttpRequest();
				req.onreadystatechange = processStateChange;
				try {
					 req.open("GET", url, true);
				} catch (e) {
					 alert(e);
				}
				req.send(null);
			} else if (window.ActiveXObject) { // IE

				 req = new ActiveXObject("Microsoft.XMLHTTP");
				if (req) {
					 req.onreadystatechange = processStateChange;
					 req.open("GET", url, true);
					 req.send();
				 }
			}
	  }

Within the retrieveURL() method, the line req.onreadystatechange = processStateChange (note: no brackets) tells the browser to call the processStateChange() method once the server sends back its response. This method (now standard in AJAX) also determines whether it should use the Internet Explorer (ActiveX) or Netscape/Mozilla (XmlHttpRequest) object to ensure cross-browser compatibility.

Now when the XMLHttpRequest object is created , we ask the browser to call the processstatechange method when we get the response from the server.

Step 3: Configure action path in struts-config

This is the same old struts functioning.

“’showCharacters.do” is configured in the struts-config.xml

struts-config.xml

<action path="/showCharacters " type="ShowTVAction" validate="false" >
			<forward name="success" path="/pages/showCharacters.jsp" />
	</action>

Step 4: Write the action class

The action class has to get the value selected in the TVShow dropdown and Get the appropriate list of characters using the function getCharacters(String tvShow) .

public class ShowTVAction extends Action {

	public ActionForward execute(ActionMapping mapping, ActionForm inForm, HttpServletRequest request, HttpServletResponse response) throws Exception {

		 // Get a list of characters associated with the select TV show
		 String tvShow = (String)request.getParameter("tvShow");
			if (tvShow == null) {
				 tvShow = "";
			}
			ArrayList characters = getCharacters(tvShow);
			request.getSession().setAttribute("characters", characters);
		 response.setContentType("text/html");
		 return mapping.findForward("success");
	  } // End execute()

	  // This method returns a list of characters for a given TV show.  If no TV
	  // show is selected, i.e., initial page view, am empty ArrayList is returned.

	  private ArrayList getCharacters (String tvShow) {

		 ArrayList al = new ArrayList();

			if (tvShow.equalsIgnoreCase("Lissie Mcguire")) {
				 al.add("Lizzie Mcguire");
				 al.add("Mathew Mcguire");
				 al.add("Miranda");
				 al.add("Gordon");
		 }

		 if (tvShow.equalsIgnoreCase("That’s so Raven ")) {
				al.add("Raven");
				al.add("Chelse”);
				al.add("Orlanda");
				al.add("Victor Backstor");
				al.add("Cory Backstor");
			}

		if (tvShow.equalsIgnoreCase("Dhoom machale ")) {
				al.add("Priyanka");
				al.add("Koyel");
				al.add("Nehal");
				al.add("Aadhiraj");
				al.add("Maleni");
			}

			return al;

	  } // End getCharacters()

	} // End class

Then it sets the Appropriate characters in the session and returns the keyword “success” Thus the control passes to showCharacters.jsp

Step 5: Write the contents you need to reload in the characters drop down (“ShowCharacters.jsp”)

In the showCharacters.jsp we load the contents of the characters drop down by taking their values from the session. Remember to add the tag libraries and surround the code with a form tag.

ShowCharacters.jsp

<html:select property="TVShowSelect">
		  <logic:present name="characters">
				<%ArrayList ch = (ArrayList)  request.getSession().getAttribute("characters");
				String[] s = new String[ch.size()];
				ch.toArray(s);
				for(int i=0;i<s.length;i++)
				{%>
					 <html:option value ="<%=s[i] %>" ></html:option>
				<%} %>
		  </logic:present>
	</html:select>

Thus the showCharacters.jsp is the response from the Back end server. Once the response form the server is got by the browser. It calls the processStateChange() method

Step 6: Updating the Web Page with the AJAX Response

So far, we have looked at the JavaScript to do the AJAX call (listed above) and the Struts Action, ActionForm, and JSP (mostly the same, with the addition of tags). To complete our understanding of the Struts-AJAX project, we need to look at the following JavaScript function that is responsible for updating the current web page when the results from the server are received.

processStateChange(): The method name that we set before making the AJAX call. The XMLHttpRequest/Microsoft.XMLHTTP object calls this method once the server has completed sending back its response.

function processStateChange() {
			if (req.readyState == 4) { // Complete
			if (req.status == 200) { // OK response
					document.getElementById("characters").innerHTML = req.responseText;
			} else {
				 alert("Problem: " + req.statusText);
			 }
		 }
	  }

Here readystate is checked .If it is equal to 4 , it means the response is completely received and the status of the response is checked to 200.

If everything fit in, the response is set as the innerHTML of the span “characters”. We can also give the response to a div.

Thus we have done a asynchronous call to the back end and got the response and set it to a span element. Only the contents of the span have been reloaded while the rest of the page remained there.

Flow of Control

By adding the above JavaScript code to our application, the following steps now happen on the server and on the browser.

• The page loads as per a normal Struts application.
• The user changes a dropdown value, triggering an onChange() event, which calls the retrieveURL() JavaScript function
• This JavaScript function makes a (background) call to the Struts Action on the server
• This JavaScript function also sets the name of a second JavaScript function, which will be called when the server response is finished. In this case, it is set to the processStateChange() method.
• As expected, when the server response is finished, the processStateChange() method is called.
• The JavaScript sets the response to a span in the page

New Features in Struts 2.0 for AJAX

One of the useful enhancements in Struts 2.0 is the introduction of AJAX Theme

The Ajax theme extends the xhtml theme with AJAX features. The theme uses the popular DOJO AJAX/JavaScript toolkit. The new AJAX features include:

• AJAX Client Side Validation
• Remote form submission support (works with the submit tag as well)
• An advanced div template that provides dynamic reloading of partial HTML
• An advanced a template that provides the ability to load and evaluate JavaScript remotely
• An AJAX-only tabbed Panel implementation
• A rich pub-sub event model
• Interactive auto complete tag

The framework provides a set of tags to help you ajaxify your applications, on Dojo.

To use the Ajax tags you need to set the “theme” attribute to “Ajax”.Use the head tag to configure the page for the Ajax theme.

URL

The “href” attribute must contain a url built with the URL tag
Example:

 Initial Content

Set the “debug” attribute of the head tag to “true” to display debug information on the bottom of the page

Indicators

Use indicators to notify the user that a request is in progress. The indicator should be hidden when the page is loaded.

Dynamic Div

The div tag is a content area that can load its content asynchronously. The div tag can be forced to reload its content using topics. To define the topics that will trigger the refresh of the panel, use the “listenTopics” attribute. This tag will load its content when the page is loaded, unless “autoStart” is set to “false”.
While Dojo supports crossdomain XHR using IFrames, the S2 Ajax tags do not (yet)

This div will refresh every time the topics “/refresh0″ or “/refresh1″ are published:

to publish a topic use.

dojo.event.topic.publish("/refresh”);

Retrieve Remote Data

The simplest way to use the div tag is to provide an href attribute. For example

What this does after the HTML page is completely loaded; the specified URL will be retrieved asynchronously in the browser. The entire contents returned by that URL will be injected in to the div and will update every minute after a two second delay: Include the attribute errorText in case the URL is not loaded

errorText="Unable to contact weather server"

Submit

The submit tag can be used to update the content of its “targets” attribute with text returned from the asynchronous request. “targets” is a comma-delimited list of element ids. The “targets” attribute is optional.

Regular submit button that will update the content of div1:

For using Submit button using an image add the attribute src

src="${pageContext.request.contextPath}/images/struts-rocks.gif"

If the submit button is used inside a form (href is not required on this case), the form will be submitted asynchronously using
A submit button can be used to submit a form, even if it is outside the form, using “formId”, “formFilter” and “href”. Note that in this case “href” is required.

 <input type="textbox" name="data" />

Anchor

The anchor tag, like the submit tag; can be used to update the content of its “targets” attribute with text returned from the asynchronous request. “Targets” is a comma-delimited list of element ids. The “targets” attribute is optional.

This anchor will update the content of div1 and div2 with text returned form “/AjaxTest.action”

Update divs If the anchor tag is used inside a form (href is not required on this case), the form will be submitted asynchronously:

	  <input type="textbox" name="data" />
	  Submit form

Using the anchor tag to submit a form:

	  <input type="textbox" name="data" />

	Submit form

AJAX Client Side Validation

• Ajax Validation requires DWR servlet being setup, Dojo and the Ajax theme being used.
• In the Ajax theme, DWR is used for normal validation while Dojo handles everything else (widgets, XHR, browser JS events etc.)
• In order for validation to function properly it is advised to use standard Struts Tags

Setup DWR

DWR could be setup by having the following dwr configuration (dwr.xml) at /WEB-INF/ directory. If it needs to be in other places.

A DWRServlet need to be registered with the web application as well. The following shows a typical web.xml with DWRSerlvet.

		   dwr
		   uk.ltd.getahead.dwr.DWRServlet

			   debug
			   true

	<!-- JavaServer Faces Servlet Configuration, not used directly -->

		faces
		javax.faces.webapp.FacesServlet
		1

		<!-- JavaServer Faces Servlet Mapping, not called directly -->

		   faces
		   *.action

		   dwr
		   /dwr/*

Add a form attribute

Add the attribute validate to the. The validate=”true” option is set for thetag to enable onblur-triggered validation

Validation - Basic

Now as usual have a form bean for this form with getters and setters and constructors, and configure the validation.xml for required fields

You must enter a name1319
				Only people ages 13 to 19 may take this quiz

Summary

This is a simple introduction to Ajax.Start implementing it and you will find it simple, easy and attractive. One can use it to do many different things. It all accounts your creativity. It is a good approach in many cases, but will not be appropriate in others. If reaching the maximum possible audience is your goal, you would want to stay away from this. If a user disabling scripting in their browser might be a concern (and your site wouldn’t be any good without it), this probably isn’t a good answer either. There are other reasons to stay away from it in some situations, but the bottom line is treat it like any other tool in your toolbox: it will be right for some jobs, maybe “not so” for others.

http://localhost:8080/hello

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

Interceptors provide Pre-processing and Post-processing functionality for a Request or a Response object in a Web Application. For general information about Interceptors, readers can go through  this section 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 name attribute 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.

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 Action class 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 Action class 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.

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 Mappings defined 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>

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.

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>

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
package element,

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 Exceptions within 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 MyPackage2 will be applicable only for MyAction3 and MyAction4 action 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 I1 and
I2, Results R1 and R2 and Exceptions E1 and E2. If we say some Package called P2 extends P1, then all the elements that are available in P1 becomes visible to Package P2. Package Extension is very similar to Class Inheritance which we normally see in any kind of Object Oriented Language.

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 name attribute. 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.

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 Validation for 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 Validations are 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 Validation as 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.

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.

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 map the set of fields participating in Validations against their Validation Rules.

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 Messages that 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("...");

Conclusion

Though Struts 2.0 has more new features to its credit, this article just provides only the basic piece of information. It walked-through about how Struts 2.0 fits into the Bigger MVC2 Architecture. Then the Flow of the Client Request into the Struts Framework is explained in detail. Following that, some samples regarding the structure of a Struts Configuration File. Then the second section primarily focusses on the new Struts Validation Features with the various types of Validations that can be performed on field components.