Page History

...

The default Interceptor stack is designed to serve the needs of most applications. Most applications will not need to add Interceptors or change the Interceptor stack.

Many Actions share common concerns. Some Actions need input validated. Other Actions may need a file upload to be pre-processed. Another Action might need protection from a double submit. Many Actions need drop-down lists and other controls pre-populated before the page displays.

The Struts Action Framework framework makes it easy to share solutions to these concerns using an "Interceptor" strategy. When you request a resource that maps to an "action", the framework invokes the Action object. But, before the Action is executed, the invocation can be intercepted by another object. After the Action executes, the invocation could be intercepted again. Unsurprisingly, we call these objects "Interceptors."

2

Understanding Interceptors

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.

...

The Interceptors are defined in a stack that specifies the execution order. In some cases, the order of the Interceptors on the stack can be very important.

Configuring Interceptors

...

Stacking Interceptors

With most web applications, we find ourselves wanting to apply the same set of Interceptors over and over again. Rather than reiterate the same list of Interceptors, we can bundle these Interceptors together using an Interceptor Stack.

...

Looking inside actionstruts-default.xml, we can see how it's done.

The Default Configuration

...

<!DOCTYPE xwork PUBLIC "-//OpenSymphony Group//XWork 1.0//EN" "http://www.opensymphony.com/xwork/xwork-1.1.dtd">

<!-- // START SNIPPET: webwork-default -->
<xwork>
    <package name="action-default">
        <result-types>
            <result-type name="chain" class="com.opensymphony.xwork.ActionChainResult"/>
            <result-type name="dispatcher" class="org.apache.struts.action2.dispatcher.ServletDispatcherResult"
                         default="true"/>
            <result-type name="freemarker" class="org.apache.struts.action2.views.freemarker.FreemarkerResult"/>
            <result-type name="httpheader" class="org.apache.struts.action2.dispatcher.HttpHeaderResult"/>
            <result-type name="jasper" class="org.apache.struts.action2.views.jasperreports.JasperReportsResult"/>
            <result-type name="redirect" class="org.apache.struts.action2.dispatcher.ServletRedirectResult"/>
            <result-type name="redirect-action"
                         class="org.apache.struts.action2.dispatcher.ServletActionRedirectResult"/>
            <result-type name="stream" class="org.apache.struts.action2.dispatcher.StreamResult"/>
            <result-type name="velocity" class="org.apache.struts.action2.dispatcher.VelocityResult"/>
            <result-type name="xslt" class="org.apache.struts.action2.views.xslt.XSLTResult"/>
        </result-types>

        <interceptors>
            <interceptor name="alias" class="com.opensymphony.xwork.interceptor.AliasInterceptor"/>
            <interceptor name="autowiring"
                         class="com.opensymphony.xwork.spring.interceptor.ActionAutowiringInterceptor"/>
            <interceptor name="chain" class="com.opensymphony.xwork.interceptor.ChainingInterceptor"/>
            <interceptor name="component" class="com.opensymphony.xwork.interceptor.component.ComponentInterceptor"/>
            <interceptor name="conversionError"
                         class="org.apache.struts.action2.interceptor.WebWorkConversionErrorInterceptor"/>
            <interceptor name="external-ref" class="com.opensymphony.xwork.interceptor.ExternalReferencesInterceptor"/>
            <interceptor name="execAndWait" class="corg.apache.struts.action2.interceptor.ExecuteAndWaitInterceptor"/>
            <interceptor name="exception" class="com.opensymphony.xwork.interceptor.ExceptionMappingInterceptor"/>
            <interceptor name="fileUpload" class="com.opensymphony.webwork.interceptor.FileUploadInterceptor"/>
            <interceptor name="i18n" class="com.opensymphony.xwork.interceptor.I18nInterceptor"/>
            <interceptor name="logger" class="com.opensymphony.xwork.interceptor.LoggingInterceptor"/>
            <interceptor name="model-driven" class="com.opensymphony.xwork.interceptor.ModelDrivenInterceptor"/>
            <interceptor name="params" class="com.opensymphony.xwork.interceptor.ParametersInterceptor"/>
            <interceptor name="prepare" class="com.opensymphony.xwork.interceptor.PrepareInterceptor"/>
            <interceptor name="static-params" class="com.opensymphony.xwork.interceptor.StaticParametersInterceptor"/>
            <interceptor name="servlet-config" class="org.apache.struts.action2.interceptor.ServletConfigInterceptor"/>
            <interceptor name="sessionAutowiring"
                         class="org.apache.struts.action2.spring.interceptor.SessionContextAutowiringInterceptor"/>
            <interceptor name="timer" class="com.opensymphony.xwork.interceptor.TimerInterceptor"/>
            <interceptor name="token" class="com.opensymphony.webwork.interceptor.TokenInterceptor"/>
            <interceptor name="token-session"
                         class="com.opensymphony.webwork.interceptor.TokenSessionStoreInterceptor"/>
            <interceptor name="validation" class="com.opensymphony.xwork.validator.ValidationInterceptor"/>
            <interceptor name="workflow" class="com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor"/>

            <!-- Basic stack -->
            <interceptor-stack name="basicStack">
                <interceptor-ref name="exception"/>
                <interceptor-ref name="servlet-config"/>
                <interceptor-ref name="prepare"/>
                <interceptor-ref name="static-params"/>
                <interceptor-ref name="params"/>
                <interceptor-ref name="conversionError"/>
            </interceptor-stack>

            <!-- Sample validation and workflow stack -->
            <interceptor-stack name="validationWorkflowStack">
                <interceptor-ref name="basicStack"/>
                <interceptor-ref name="validation"/>
                <interceptor-ref name="workflow"/>
            </interceptor-stack>

            <!-- Sample file upload stack -->
            <interceptor-stack name="fileUploadStack">
                <interceptor-ref name="fileUpload"/>
                <interceptor-ref name="basicStack"/>
            </interceptor-stack>

            <!-- Sample WebWork Inversion of Control stack
                 Note: WebWork's IoC is deprecated - please
                 look at alternatives such as Sprint -->
            <interceptor-stack name="componentStack">
                <interceptor-ref name="component"/>
                <interceptor-ref name="basicStack"/>
            </interceptor-stack>

            <!-- Sample model-driven stack  -->
            <interceptor-stack name="modelDrivenStack">
                <interceptor-ref name="model-driven"/>
                <interceptor-ref name="basicStack"/>
            </interceptor-stack>

            <!-- Sample action chaining stack -->
            <interceptor-stack name="chainStack">
                <interceptor-ref name="chain"/>
                <interceptor-ref name="basicStack"/>
            </interceptor-stack>

            <!-- Sample i18n stack -->
            <interceptor-stack name="chainStack">
                <interceptor-ref name="i18n"/>
                <interceptor-ref name="basicStack"/>
            </interceptor-stack>

            <!-- Sample execute and wait stack.
                 Note: execAndWait should always be the *last* interceptor. -->
            <interceptor-stack name="executeAndWaitStack">
                <interceptor-ref name="basicStack"/>
                <interceptor-ref name="execAndWait"/>
            </interceptor-stack>

            <!-- A complete stack with all the common interceptors in place.
                 Generally, this stack should be the one you use, though it
                 may process additional stuff you don't need, which could
                 lead to some performance problems. Also, the ordering can be
                 switched around (ex: if you wish to have your components
                 before prepare() is called, you'd need to move the component
                 interceptor up -->
            <interceptor-stack name="defaultStack">
                <interceptor-ref name="exception"/>
                <interceptor-ref name="alias"/>
                <interceptor-ref name="prepare"/>
                <interceptor-ref name="servlet-config"/>
                <interceptor-ref name="i18n"/>
                <interceptor-ref name="chain"/>
                <interceptor-ref name="model-driven"/>
                <interceptor-ref name="fileUpload"/>
                <interceptor-ref name="static-params"/>
                <interceptor-ref name="params"/>
                <interceptor-ref name="conversionError"/>
                <interceptor-ref name="validation"/>
                <interceptor-ref name="workflow"/>
            </interceptor-stack>

            <!-- The completeStack is here for backwards compatibility for
                 applications that still refer to the defaultStack by the
                 old name -->
            <interceptor-stack name="completeStack">
                <interceptor-ref name="defaultStack"/>
            </interceptor-stack>
        </interceptors>

        <default-interceptor-ref name="defaultStack"/>
    </package>
</xwork>
<!-- // END SNIPPET: webwork-default -->

Since we included action-default.xml in our action.xml, all the predefined interceptors and stacks are available for us to use in our actions.

In addition to the prepackaged Interceptors, action-default.xml includes prepackaged combinations in named Interceptor Stacks.

Building Your Own Interceptor

If the stock Interceptors aren't enough, you can implement custom Interceptors to solve a new problem or and old problem differently.

Suppose several pages in an application would like to to display a greeting that changes according to the time of day. A good way to solve this use case is to use an Interceptor to place the greeting in the session on each request. As soon as the time of day changes, so would the greeting. As an Interceptor, the greeting can be created automatically, so that the Actions need not be bothered.

Implementing a Greeting Interceptor

1. Create an Interceptor class by implementing the com.opensymphony.xwork.interceptor.Interceptor interface (bundled in the xwork-1.1.jar provided with the framework distribution).
2. Declare the class in your XML configuration file (action.xml) using the element <interceptor /> nested within <interceptors />.
3. Create stacks of Interceptors, using the <interceptor-stack /> element (optional).
4. Determine which Interceptors are used by which mapping, using <interceptor-ref /> or <default-interceptor-ref />. The <interceptor-ref> defines the interceptors to be used in a specific action. The <default-interceptor-ref /> determines the default interceptor stack to be used by all actions that do not specify their own <interceptor-ref />.

Coding the Interceptor class

...

package tutorial;

import java.util.Calendar;
import com.opensymphony.xwork.interceptor.Interceptor;
import com.opensymphony.xwork.ActionInvocation;

public class GreetingInterceptor implements Interceptor {
  public void init() { }
  public void destroy() { }
  public String intercept(ActionInvocation invocation) throws Exception {
    Calendar calendar = Calendar.getInstance();
    int hour = calendar.get(Calendar.HOUR_OF_DAY);
    String greeting = (hour < 6) ? "Good evening" :
        ((hour < 12) ? "Good morning":
 	((hour < 18) ? "Good afternoon": "Good evening"));

     invocation.getInvocationContext().getSession().put("greeting", greeting);

     String result = invocation.invoke();

     return result;
  }
}

Coding the configuration

...

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

<struts>
  <include file="action-default.xml" />

  <package name="default" extends="action-default">
     <interceptors>
       <interceptor name="greeting" class="tutorial.GreetingInterceptor" />
     </interceptors>

     <action name="greeting" class="tutorial.GreetingAction">
 	<interceptor-ref name="greeting" />
 	<result name="success" type="velocity">greeting.vm</result>
      </action>

      <!-- other action mappings -->

   </package>
 </struts>

Coding the Action class

...

package tutorial;

import com.opensymphony.xwork.ActionSupport;

public class GreetingAction extends ActionSupport {
  public String execute() throws Exception
  {
    return SUCCESS;
  }
}

Coding the result page

...

<html>
  <head>
    <title>Understanding Interceptors</title>
   </head>
   <body>
     #set ($ses = $req.getSession())
     <p><b>${ses.getAttribute('greeting')}!</b></p>
   </body>
 </html>

{snippet:id=all|lang=xml|url=struts2/core/src/main/resources/struts-default.xml}Since the struts-default.xml is included in the application's configuration by default, all of the predefined interceptors and stacks are available "out of the box".

Framework Interceptors

Interceptor classes are also defined using a key-value pair specified in the Struts configuration file. The names specified below come specified in struts-default.xml. If you extend the struts-default package, then you can use the names below. Otherwise, they must be defined in your package with a name-class pair specified in the <interceptors> tag.

...

Since 2.0.7, Interceptors and Results with hyphenated names were converted to camelCase. (The former model-driven is now modelDriven.) The original hyphenated names are retained as "aliases" until Struts 2.1.0. For clarity, the hyphenated versions are not listed here, but might be referenced in prior versions of the documentation.

Method Filtering

{snippet:id=javadoc|javadoc=true|url=com.opensymphony.xwork2.interceptor.MethodFilterInterceptor}

Interceptor Parameter Overriding

Interceptor's parameter could be overridden through the following ways :

Method 1:

...

Method 2:

...

In the first method, the whole default stack is copied and the parameter then changed accordingly.

In the second method, the interceptor-ref refers to an existing interceptor-stack, namely defaultStack in this example, and override the validator and workflow interceptor excludeMethods attribute. Note that in the param tag, the name attribute contains a dot (.) the word before the dot(.) specifies the interceptor name whose parameter is to be overridden and the word after the dot (.) specifies the parameter itself. The syntax is as follows:

...

Note also that in this case the interceptor-ref name attribute is used to indicate an interceptor stack which makes sense as if it is referring to the interceptor itself it would be just using Method 1 describe above.

Method 3:

...

Interceptor Parameter Overriding Inheritance

Parameters override are not inherited in interceptors, meaning that the last set of overridden parameters will be used. For example, if a stack overrides the parameter "defaultBlock" for the "postPrepareParameterFilter" interceptor as:

...

and an action overrides the "allowed" for "postPrepareParameterFilter":

...

Then, only "allowed" will be overridden for the "postPrepareParameterFilter" interceptor in that action, the other params will be null.

Lazy parameters

...

This functionality was added in Struts 2.5.9

It is possible to define an interceptor with parameters evaluated during action invocation. In such case the interceptor must be marked with WithLazyParams interface. This must be developer's decision as interceptor must be aware of having those parameters set during invocation and not when the interceptor is created as it happens in normal way.

Params are evaluated as any other expression starting with from action as a top object.

...

Please be aware that order of interceptors can matter when want to access parameters passed via request as those parameters are set by Parameters Interceptor.

Order of Interceptor Execution

Interceptors provide an excellent means to wrap before/after processing. The concept reduces code duplication (think AOP).

...

Note that some Interceptors will interrupt the stack/chain/flow ... so the order is very important.

Interceptors implementing com.opensymphony.xwork2.interceptor.PreResultListener will run after the Action executes but before the Result executes.

...

FAQ

• How do we configure an Interceptor to be used with every Action?
• How do we get access to the session?
• How can we access the HttpServletRequest?
• How can we access the HttpServletResponse?
• How can we access request parameters passed into an Action?
• How do we access static parameters from an Action?
• Can we access an Action's Result?
• How do I obtain security details (JAAS)?
• Why isn't our Prepare interceptor being executed?
• How do we upload files?

Next: Writing Interceptors

How the code works

Let's take a look at our Interceptor class first. An Interceptor must implement com.opensymphony.xwork.interceptor.Interceptor which expects three methods.

• init() is called during interceptor initialization,
• destroy() is called during destruction, and most importantly,
  • intercept(ActionInvocation invocation) is where we place the code that does the work.

The Greeting Interceptor returns the result from invocation.invoke. The invokemethod executes the next Interceptor in the stack or, if this is the last Interceptor, the appropriate method of the Action class. The invokemethod grants the Interceptor the power to short-circuiting the Action Invocation. Instead of calling invoke, the Interceptor can return a result String and bypass any remaining Interceptors on the stack and the Action's execute method.

An Interceptor can also execute code after the Action method executes. Just place more code after the invocation.invoke call. Control returns to each Interceptor on the stack in reverse order. When the call to invoke returns, you can continue processing.

Many Interceptors execute code only before or after the Action, but some do execute code in both places. To make coding Interceptors a little easier, the framework provides an abstract class that implements the "before and after" behaviour. Instead of calling invoke}] itself, an Interceptor can extend {{com.opensymphony.xwork.interceptor.AroundInterceptor and implement the methods before(ActionInvocation invocation) and after(ActionInvocation dispatcher, String result).

Summary

The Interceptor strategy promotes reusability and simplicity. Interceptors make it easier to separate concerns, so that we can solve one problem at a time. The best part is that each application, and each Action, controls exactly what Interceptors are used in what order.

...

Next

...

Onward to Understanding Validation

...

Prev

...