Getting Started with Apache Struts

Tutorial - Apache Struts 2 - From Soup to Nuts - Part 3


It Takes a Village – Actions, Interceptors, Validators, Results

Web pages are only the last mile between the user and the backend business logic. In order to acquire the data that a dynamic page needs, a request passes through a set of handlers. The image below shows this in context.

Lights, Cameras – Actions

Actions are the framework's basic unit of work. Most framework requests are handled by an Action, with help from Interceptors, Results, and the Struts Tags. An application can map an action handler to logical resource names, like Welcome.action or AccountInsert.action. When a browser submits a request for one of these resources, the framework selects an Action class to handle the exchange. The input values from the request (if any) are transferred to properties on an Action class (or some other class of your choosing). The framework then calls a method on the Action to invoke the business logic associated with the request. The class can return a string token to indicate the outcome of the transaction. Usually, these tokens are generic terms like "success", "failure", "input", "error", or "cancel". The framework passes the token returned by an Action to a Result handler for further processing.

Getting There from Here – Results

The result handler either creates output or dispatches to another resource, like a server page, to create the output. There are several result handlers bundled with the framework and several more are available as plugins. For example, there are plugins for rendering reports with JFreeChart or JasperReports.

Another plugin converts output to JSON for AJAX applications. Yet another lets Struts 2 applications utilize JavaServer Faces components as a result. Other custom results can be created and plugged into the framework as needed. Each action handler can have one or more result handlers, mapped to whatever result types are needed.

Regardless of what type of result is being generated, the action handler only needs to return a logical name. The action does not need to know how the response is being handled.

Thank You Sir, May I have Another – Interceptors

Most of the framework's business-logic utility is provided by Interceptors. All requests can be handled by a single set of Interceptors, or different sets of Interceptors can handle different requests.

Interceptors can invoke code both before and after the Action executes, encapsulating standard utility that can be shared between Actions into a reusuable object. Services like property population, validation, and authorization are provided by standard Interceptors.

The set of Interceptors acts as a “gauntlet” for the request. The request object passes through each Interceptor in turn. The Interceptor can ignore the request, or act on the request, as appropriate.

Trust but Verify – Validators

Validators vet incoming data and generate an error message when input is invalid. The framework provides all the validators that most applications will need, though custom Validators are easy to implement for special situations.

Ready, Set, Go – Annotations and Deployment Descriptors

A web application uses a deployment descriptor to initialize resources like filters and listeners. The web deployment descriptor is formatted as a XML document. The web container reads the XML document and creates an internal configuration object. When the container starts up, it loads and configures the components specified by the deployment descriptor.

Likewise, Struts uses an internal configuration object to tie together various parts of the application, like the Action and the Result. An application can specify the Struts configuration by using Java annotations or by providing one or more XML documents.

  • web.xml – Standard web deployment descriptor with the framework’s bootstrap components, including the FilterDispacther that detects Action URLs.
  • struts.xml – Main configuration, contains result/view types, action mappings, interceptors, and so forth.
  • struts-plugin.xml – Optional configuration file for plugins. Each plugin JAR may have its own descriptor.

Below shows a typical XML-style configuration for a logon action:

Example Logon XML Document


  <package name="default"
    <action name="Logon"
      <result type="redirect-action">MainMenu</result>
      <result name="input">/pages/Logon.jsp</result>
      <result name="cancel"
      <result name="expired"


And the corresponding annotations for the same logon action:

Example Logon Java Annotation


@Result(name="success", value="MainMenu"),
@Result(name="input", value="pages/Logon.jsp"),
@Result(name="cancel", value="Welcome",
@Result(name="expired", value="ChangePassword",
public class Logon extends ActionSupport {
// .... 


Tip – Configuration by Java annotation or by XML document are not mutually exclusive. We can use either or both in the same application.



Ted Husted
Ted Husted

What do you think?

JAX Magazine - 2014 - 03 Exclucively for iPad users JAX Magazine on Android


Latest opinions