See Interceptor Configuration for basic information about how interceptors are configured.

Overview

An interceptor is a stateless class that follows the interceptor pattern, as found in {@link javax.servlet.Filter} and in AOP languages.

Interceptors are objects that dynamically intercept Action invocations. They provide the developer with the opportunity to define code that can be executed before and/or after the execution of an action. They also have the ability to prevent an action from executing. Interceptors provide developers a way to encapulate common functionality in a re-usable form that can be applied to one or more Actions.

Interceptors must be stateless and not assume that a new instance will be created for each request or Action. Interceptors may choose to either short-circuit the ActionInvocation execution and return a return code (such as com.opensymphony.xwork.Action#SUCCESS), or it may choose to do some processing before and/or after delegating the rest of the procesing using ActionInvocation#invoke().


Webwork & XWork Interceptors

Interceptor classes are also defined using a key-value pair specified in the xwork configuration file. The names specified below come specified in webwork-default.xml. If you extend the webwork-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.

Interceptor Name Description
Alias Interceptor alias Converts similar parameters that may be named differently between requests.
Chaining Interceptor chain Makes the previous action's properties available to the current action. Commonly used together with <result type="chain"> (in the previous action).
Component Interceptor component Enables and makes the components available to the Actions. Refer to components.xml
Conversion Error Interceptor conversionError adds conversion errors from the ActionContext to the Action's field errors
Create Session Interceptor createSession create an HttpSession automatically, usefull with certain interceptor (eg. TokenInterceptor) when an HttpSession is required in order to work properly
Execute and Wait Interceptor execAndWait an interceptor that executes the action in the background and then sends the user off to an intermediate waiting page.
Exception Interceptor exception Maps exceptions to a result.
File Upload Interceptor fileUpload an interceptor that adds easy access to file upload support. See the javadoc for more info
I18n Interceptor i18n remembers the locale selected for a user's session
Logger Interceptor logger Outputs the name of the action
Model Driven Interceptor model-driven If the action implements ModelDriven, pushes the getModel() result onto the valuestack.
Parameters Interceptor params Sets the request parameters onto the action.
Prepare Interceptor prepare If the action implements Preparable, calls its prepare() method.
Scope Interceptor scope simple mechanism for storing action state in the session or application scope
Servlet Config Interceptor servlet-config Give access to HttpServletRequest and HttpServletResponse (think twice before using this since this ties you to the Servlet api)
Static Parameters Interceptor static-params Sets the xwork.xml defined parameters onto the action. These are the <param> tags that are direct children of the <action> tag.
Timer Interceptor timer Outputs how long the action (including nested interceptors and view) takes to execute
Token Interceptor token Checks for valid token presence in action, prevents duplicate form submission
Token Session Interceptor token-session Same as above, but storing the submitted data in session when handed an invalid token
Validation Interceptor validation Performs validation using the validators defined in {Action}-validation.xml
Workflow Interceptor workflow Calls the validate method in your action class. If action errors created then it returns the INPUT view.
Parameter Filter Interceptor paramFilter Removes parameters from the list of those available to actions etc.
Parameter Remover Interceptor paramRemover Removes parameter from parameter map if their param name and value matches a certain configurable value defined through paramNames and paramValues attribute respectively.
Session Invalidation Interceptor sessionInvalidation invalidates the http session, either now or in the next comming request where this interceptor is present in the interceptor stack.
Flash Interceptor flash store/retrieve action from http session and push them into stack, such that action (and its information stored) will be available after redirect.
Debugging Interceptor debugging Printing out content in value stack
Cookie Interceptor cookie Inject cookie with a certain configurable name / value into action
Message Store Interceptor store Store field errors / action errors / action messages into HttpSession and also retrive them from HttpSession depending on the operationMode the interceptor is in to allow field errors / action errors / action messages to be available throughout different Http requests.

Method Filtering

An abstract Interceptor that is applied to selectively according to specified included/excluded method lists.

Setable parameters are as follows:

  • excludeMethods - methods name to be excluded
  • includeMethods - methods name to be included

NOTE: If method name are available in both includeMethods and excludeMethods, it will still be considered as an included method. In short includeMethods takes precedence over excludeMethods.

Interceptors that extends this capability would be :-

  • TokenInterceptor
  • TokenSessionStoreInterceptor
  • DefaultWorkflowInterceptor
  • ValidationInterceptor

Interceptor Parameter Overriding

Interceptor's parameter could be overriden through the following ways :-

Method 1: 

<action name="myAction" class="myActionClass">
  <interceptor-ref name="exception"/>
    <interceptor-ref name="alias"/>
    <interceptor-ref name="params"/>
    <interceptor-ref name="servlet-config"/>
    <interceptor-ref name="prepare"/>
    <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">
      <param name="excludeMethods">myValidationExcudeMethod</param>
    </interceptor-ref>
    <interceptor-ref name="workflow">
      <param name="excludeMethods">myWorkflowExcludeMethod</param>
    </interceptor-ref>
</action>

Method 2: 

<action name="myAction" class="myActionClass">
  <interceptor-ref name="defaultStack">
    <param name="validation.excludeMethods">myValidationExcludeMethod</param>
    <param name="workflow.excludeMethods">myWorkflowExcludeMethod</param>
  </interceptor-ref>
</action>

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

In the second method, the refer to an existing interceptor-stack, namely default-stack in this example, and override the validator and workflow interceptor excludeMethods typically in this case. Note that in the tag, the name attribute contains a dot (.) the word before the dot(.) specifies the interceptor name whose parameter is to be overriden and the word after the dot (.) specifies the parameter itself. Essetially it is as follows :-

   <interceptor-name>.<parameter-name>

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

Nested Parameter Overriding

WebWork 2.2.5 and earlier

There's a bug (XW-516) that prevents this from working for version earlier thatn WebWork-2.2.6.

Interceptor stack parameter overriding could be nested into as many level as possible, though it would be advisable not to nest it too deep as to avoid confusion, For example, 

<interceptor name="interceptor1" class="foo.bar.Interceptor1" />
<interceptor name="interceptor2" class="foo.bar.Interceptor2" />
<interceptor name="interceptor3" class="foo.bar.Interceptor3" />
<interceptor name="interceptor4" class="foo.bar.Interceptor4" />
<interceptor-stack name="stack1">
    <interceptor-ref name="interceptor1" />
</interceptor-stack>
<interceptor-stack name="stack2">
    <interceptor-ref name="intercetor2" />
    <interceptor-ref name="stack1" />
</interceptor-stack>
<interceptor-stack name="stack3">
    <interceptor-ref name="interceptor3" />
    <interceptor-ref name="stack2" />
</interceptor-stack>
<interceptor-stack name="stack4">
    <interceptor-ref name="interceptor4" />
    <interceptor-ref name="stack3" />
 </interceptor-stack>
Assuming the interceptor has the following properties
Interceptor property
Interceptor1 param1
Interceptor2 param2
Interceptor3 param3
Interceptor4 param4
We could override them as follows :- 
   <action ... >
       <!-- to override parameters of interceptor located directly in the stack  -->
       <interceptor-ref name="stack4">
          <param name="interceptor4.param4"> ... </param>
       </interceptor-ref>
   </action>
   <action ... >
       <!-- to override parameters of interceptor located under nested stack -->
       <interceptor-ref name="stack4">
           <param name="stack3.interceptor3.param3"> ... </param>
           <param name="stack3.stack2.interceptor2.param2"> ... </param>
           <param name="stack3.stack2.stack1.interceptor1.param1"> ... </param>
       </interceptor-ref>
   </action>

Order of Interceptor Execution

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

<interceptor-stack name="xaStack">
  <interceptor-ref name="thisWillRunFirstInterceptor"/>
  <interceptor-ref name="thisWillRunNextInterceptor"/>
  <interceptor-ref name="followedByThisInterceptor"/>
  <interceptor-ref name="thisWillRunLastInterceptor"/>
</interceptor-stack>

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

Interceptors implementing com.opensymphony.xwork.interceptor.PreResultListener will run after the Action executes its action method but before the Result executes

thisWillRunFirstInterceptor
  thisWillRunNextInterceptor
    followedByThisInterceptor
      thisWillRunLastInterceptor
        MyAction1
        MyAction2 (chain)
        MyPreResultListener
        MyResult (result)
      thisWillRunLastInterceptor
    followedByThisInterceptor
  thisWillRunNextInterceptor
thisWillRunFirstInterceptor