Page History

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

[Interceptors can execute code before and after an Action is invoked. Most of the framework's core features are functionality is implemented as Interceptors. Object population and Features like double-submit guards, type conversion, object population, validation, file uploads, double-submit guards, component setup, and more, are all implemented with Interceptorsupload, 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 supports.

Interceptors can be configured on a per-action basis. Custom Your own custom Interceptors can be mixed-and-matched with the Interceptors bundled with the framework. Interceptors "set the stage" for the Action classes, doing much of the "heavy lifting" before the Action executes. The Interceptor strategy promotes reusability and simplicity.When you access request an "action" URI, the framework invokes the Action object. But, before the Action is executed, the invocation can be intercepted by another object. (Hence the name.) After the Action executes, the invocation can be intercepted again, doing much of the "heavy lifting" before the Action executes.

Action Lifecyle

Interceptors can interrupt the request processing, so that the Action never executesIn some cases, an Interceptor might keep an Action from firing, because of a double-submit or because validation failed. Interceptors can also change the state of an Action before it executes.

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.

...

With most web applications, you'll we find yourself ourselves wanting to apply the same set of interceptors over and over again. Rather than declare interceptor-refs for each action, you reiterate the same list of interceptors, we can bundle these interceptors together using an interceptor stack.

...

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

...

The Default Configuration

Code Block

	xml
	xml
title	action.xml

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

...

timer	clocks how long the action (including nested interceptors and view) takes to execute
logger	logs the action being executed
chain	makes the previous action's properties available to the current action. Used to make action chaining (reference: Result Types)
static-params	: sets the parameters defined in `xwork.xml` onto the action. These are the `<param />` tags that are direct children of the `<action />` tag
params	sets the request (POST and GET) parameters onto the action class. We have seen an example of this in TODO
*model-driven	if the action implements `ModelDriven`, pushes the `getModel()` result onto the Value Stack
component	enables and makes registered components available to the actions. (reference: IoC & Components)
token	checks for valid token presence in action, prevents duplicate form submission
token-session	same as above, but storing the submitted data in session when handed an invalid token;
validation	performs validation using the validators defined in {`Action}-validation.xml` (reference: Validation).
workflow	calls the validate method in your action class. If action errors created then it returns the `INPUT` view. Good to use together with the validation interceptor (reference: Validation)
servlet-config	give access to `HttpServletRequest` and `HttpServletResponse` (think twice before using this since this ties you to the Servlet API)
prepare	allows you to programmatic access to your Action class before the parameters are set on it.
conversionError	Adds field errors if any type-conversion errors occurred\
execAndWait	Spawns a separate thread to execute the action
fileUpload	Sets uploaded files as action files (File objects)

...

Building your own Interceptor

If none of the stock Interceptors meets your needs, you can implement your own Interceptor. Fortunately, this is an easy task to accomplish. Suppose we need an Interceptor that places a greeting in the session according to the time of the day (morning, afternoon or evening). Here's how we could implement it:aren't enough, we 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

Create an Interceptor class by implementing Create an Interceptor class, which is a class that implements the com.opensymphony.xwork.interceptor.Interceptor interface (bundled in the xwork-1.1.jar provided with the framework distribution).
Declare the class in your XML configuration file action.xml) using the element <interceptor /> nested within <interceptors />;.
Create stacks of Interceptors, using the <interceptor-stack /> element (optional);.
Determine which Interceptors are used by which mapping, using <interceptor-ref /> or <default-interceptor-ref />. The former <interceptor-ref> defines the interceptors to be used in a specific action, while the latter . 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

Code Block

	java
	java
title	"GreetingInterceptor.java"

package lesson05tutorial;

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

Code Block

	xml
	xml
title	"action.xml"

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

<xwork>
	<!-- Include webwork defaults (from WebWork JAR). -->
	<include file="webworkaction-default.xml" />

	<!-- Configuration for the default package. -->
	<package name="default" extends="webworkaction-default">
		<interceptors>
			<interceptor name="greeting" class="section02.lesson05tutorial.GreetingInterceptor" />
		</interceptors>

		<!-- Action: Lesson 5: GreetingInterceptor. --<action name="greeting" class="tutorial.GreetingAction">
		<action	<interceptor-ref name="greetingActiongreeting" class="lesson05.GreetingAction"/>
			<result name="success" type="velocity">ex01-result.vm</result>
			<interceptor-ref name="greeting" />
		</action>>greeting.vm</result>
		</action>

                <!-- other action mappings -->

	</package>
</xwork>

...

Coding the Action class

Code Block

	java
	java
title	"GreetingAction.java:"

package lesson05;

import com.opensymphony.xwork.ActionSupport;

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

...

Coding the result page

Code Block

	html
	html
title	"greeting.vm"

<html>
<head>
<title>WebWork Tutorial - Lesson 5 - Example 1<<title>Understanding Interceptors</title>
</head>
<body>

#set ($ses = $req.getSession())
<p><b>${ses.getAttribute('greeting')}!</b></p>

</body>
</html>

How the code works

Let's take a look at our interceptor Interceptor class first. As explained before, the interceptor An Interceptor must implement com.opensymphony.xwork.interceptor.Interceptor's methods: 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.

Notice that our interceptor The Greeting Interceptor returns the result from invocation.invoke() which is the method responsible for executing . The invoke method executes the next interceptor Interceptor in the stack or, if this is the last oneInterceptor, the action. This means that appropriate method of the Action class. The invoke method gives the interceptor has the power of to short-circuiting the action invocation and circuiting the Action Invocation. Instead, the Interceptor can return a result string without executing the action String without letting the Actoin execute the Action at all! Use this with caution, though.(Use this power with caution!)

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 exeucte code only before or after the Action, but some do execute code in both places. To make coding Interceptors a little easier, the framework One other thing that interceptors can do is execute code after the action has executed. To do that, just place code after the invocation.invoke() call. WebWork provides an abstract class that already implements this kind of behaviour: implements the "before and after" behaviour. Instead of calling invoke}] itself, an Interceptor can extend {{com.opensymphony.xwork.interceptor.AroundInterceptor. Just extend it and implement the methods before(ActionInvocation invocation) and after(ActionInvocation dispatcher, String result).

The xwork.xml configuration, the action class and the result page are pretty straightforward and require no further explanation.

...

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	Return to Understanding Results

Child pages

Versions Compared

Old Version 15

New Version 16

Key

The Default Configuration

Building your own Interceptor

Implementing a Greeting Interceptor

Coding the Interceptor class

Coding the configuration

Coding the Action class

Coding the result page

How the code works

Summary