Introduction to Struts 2

Target Audience

This tutorial is designed for Java programmers who need to understand the Struts 2.x framework and its application.

Prerequisites:

Before proceeding with this tutorial you should have a good understanding of the Java programming language. A basic understanding of MVC Framework and JSP or Servlet is very helpful.
This is 1 of 8 parts of tutorial series

Tutorial Content:

• Introduction to struts 2
• configuring struts 2 in eclipse
• Struts 2 hello world example
• Login page with validation in struts 2
• Struts 2 interceptors with example
• File upload in struts 2
• Struts 2 ajax example
• Struts 2 spring 3 integration example

Introduction:

Apache Struts 2 is an elegant, extensible framework for creating enterprise-ready Java web applications. The framework is designed to streamline the full development cycle, from building, to deploying, to maintaining applications over time.

Apache Struts2 was originally known as WebWork 2. After working independently for several years, the WebWork and Struts communities joined forces to create Struts2. This new version of Struts is simpler to use and closer to how Struts was always meant to be.
Struts 2 is a pull-MVC framework. i.e. the data that is to be displayed to user has to be pulled from the Action.

Struts2 supports annotation based configurations which are easy to create and more intuitive. Action class in Struts 2 act as the model in the web application. Unlike Struts 1.X, Struts 2 Action class are plain POJO objects, thus simplifying the testing of the code. Struts2 also comes with power APIs to configure Interceptors that reduce greatly the coupling in application. The view part of Struts 2 is highly configurable and it supports different result-types such as Velocity, FreeMarker, JSP, etc.

Architecture:

Above diagram describes modules in struts 2 .There are 5 modules:

1. Client-Client generates request which is processed by webContainer.Example of client can be web browser.
2. Interceptor-Interceptors can execute code before and after an Action is invoked. Most of the framework’s core functionality is implemented as Interceptors. Features like double-submit guards, type conversion, object population, validation, file upload, page preparation, and more  are all implemented with the help of Interceptors. Each and every Interceptor is pluggable, so you can decide exactly which features an Action needs to support.
3. Strut2 xml– Struts2.xml acts as a router which invokes action class for client request.
4. Action-Action module considered as a model class which invokes business service and function logic.
5. JSP-It is view part.According to action,Corresponding JSP files is rendered and result is returned to user.

Request Processing Lifecycle

1. User generates request which then goes to servlet container.
2. Servlet container invokes FilterDispatcher filter which in turn directs to appropriate action.
3. One by one Intercetors are applied before calling the Action. Interceptors performs tasks such as Logging, Validation, File Upload, Double-submit guard etc.
4. Action is executed and the Result is generated by Action.
5. The output of Action is rendered in the view (JSP, Velocity, etc) and the result is returned to the user.

Comparing between struts 1.x and struts 2.x

1. Struts1 extends the abstract base class by its action class. The problem with struts1 is that it uses the abstract classes rather than interfaces.  An Struts 2 Action may implement an Action interface, along with other interfaces to enable optional and custom services. Struts 2 provides a base ActionSupport class to implement commonly used interfaces. Albeit, the Action interface is not required. Any POJO object with a execute signature can be used as an Struts 2 Action object.
2. Struts 1 Actions are singletons and must be thread-safe since there will only be one instance of a class to handle all requests for that Action.Struts 2 Action objects are instantiated for each request, so there are no thread-safety issues.
3. Struts 1 Actions have dependencies on the servlet API since the HttpServletRequest and HttpServletResponse is passed to the execute method when an Action is invoked. Struts 2 Actions are not coupled to a container. Most often the servlet contexts are represented as simple Maps, allowing Actions to be tested in isolation.
4. A major hurdle to testing Struts 1 Actions is that the execute method exposes the Servlet API. A third-party extension, Struts TestCase, offers a set of mock object for Struts 1. Struts 2 Actions can be tested by instantiating the Action, setting properties, and invoking methods. Dependency Injection support also makes testing simpler.
5. ActonForms are used in Struts 1. These classes map with the jsp forms. The Action classes use the data in these ActonForms to populate Data Transfer Objects. But in Struts 2 Acton Forms are not used. The jsp forms direct map to POJO, and there is no need to create DTO, thereby the number of classes decreases leading to less maintenance.
6. Struts 1 uses the standard JSP mechanism for binding objects into the page context for access. Struts 2 uses a “ValueStack” technology so that the taglibs can access values without coupling your view to the object type it is rendering.
7. Struts 1 supports separate Request Processors (lifecycles) for each module, but all the Actions in the module must share the same lifecycle.  Struts 2 supports creating different lifecycles on a per Action basis via Interceptor Stacks. Custom stacks can be created and used with different Actions, as needed.
8. Struts 1 integrates with JSTL, so it uses the JSTL EL. The EL has basic object graph traversal, but relatively weak collection and indexed property support.  Struts 2 can use JSTL, but the framework also supports a more powerful and flexible expression language called “Object Graph Navigation Language” (OGNL).