|
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.
默认的Interceptor栈被设计符合大多应用的需要，大部分的应用不需要添加Interceptors或改变Interceptor栈。
|
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.
很多Action共享通用的装置。一些Action需要输入验证，其他Action可能需要文件上传被预处理。另外一些Action可能需要防止两次提交。很多Action需要在页面显示之前，dropdownlist和其他控件被预前渲染。
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."
Interceptor在一个Action前后工作。
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.
Interceptors can be configured on a per-action basis. 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.
| ion Lifecyle |
 Action Lifecyle
|
In 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.
Configuring Interceptors
<package name="default" extends="struts-default">
<interceptors>
<interceptor name="timer" class=".."/>
<interceptor name="logger" class=".."/>
</interceptors>
<action name="login"
class="tutorial.Login">
<interceptor-ref name="timer"/>
<interceptor-ref name="logger"/>
<result name="input">login.jsp</result>
<result name="success"
type="redirect-action">/secure/home</result>
</action>
</package>
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.
<package name="default" extends="struts-default">
<interceptors>
<interceptor name="timer" class=".."/>
<interceptor name="logger" class=".."/>
<interceptor-stack name="myStack">
<interceptor-ref name="timer"/>
<interceptor-ref name="logger"/>
</interceptor-stack>
</interceptors>
<action name="login"
class="tutuorial.Login">
<interceptor-ref name="myStack"/>
<result name="input">login.jsp</result>
<result name="success"
type="redirect-action">/secure/home</result>
</action>
</package>
Looking inside struts-default.xml, we can see how it's done.
The Default Configuration
<!DOCTYPE struts PUBLIC
"-//Apache Software Foundation//DTD Struts Configuration 2.0//EN"
"http://struts.apache.org/dtds/struts-2.0.dtd">
<struts>
<package name="struts-default">
<result-types>
<result-type name="chain" class="com.opensymphony.xwork.ActionChainResult"/>
<result-type name="dispatcher" class="org.apache.struts2.dispatcher.ServletDispatcherResult"
default="true"/>
<result-type name="freemarker" class="org.apache.struts2.views.freemarker.FreemarkerResult"/>
<result-type name="httpheader" class="org.apache.struts2.dispatcher.HttpHeaderResult"/>
<result-type name="jasper" class="org.apache.struts2.views.jasperreports.JasperReportsResult"/>
<result-type name="redirect" class="org.apache.struts2.dispatcher.ServletRedirectResult"/>
<result-type name="redirect-action"
class="org.apache.struts2.dispatcher.ServletActionRedirectResult"/>
<result-type name="stream" class="org.apache.struts2.dispatcher.StreamResult"/>
<result-type name="velocity" class="org.apache.struts2.dispatcher.VelocityResult"/>
<result-type name="xslt" class="org.apache.struts2.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.struts2.interceptor.WebWorkConversionErrorInterceptor"/>
<interceptor name="external-ref" class="com.opensymphony.xwork.interceptor.ExternalReferencesInterceptor"/>
<interceptor name="execAndWait" class="corg.apache.struts2.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.struts2.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"/>
<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>
<interceptor-stack name="validationWorkflowStack">
<interceptor-ref name="basicStack"/>
<interceptor-ref name="validation"/>
<interceptor-ref name="workflow"/>
</interceptor-stack>
<interceptor-stack name="fileUploadStack">
<interceptor-ref name="fileUpload"/>
<interceptor-ref name="basicStack"/>
</interceptor-stack>
<interceptor-stack name="modelDrivenStack">
<interceptor-ref name="model-driven"/>
<interceptor-ref name="basicStack"/>
</interceptor-stack>
<interceptor-stack name="chainStack">
<interceptor-ref name="chain"/>
<interceptor-ref name="basicStack"/>
</interceptor-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>
</struts>
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.
| 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). |
| Checkbox Interceptor |
checkbox |
Adds automatic checkbox handling code that
detect an unchecked checkbox and add it as a parameter with a default
(usually 'false') value. Uses a specially named hidden field to detect
unsubmitted checkboxes. The default unchecked value is overridable for
non-boolean value'd checkboxes. Minor source formatting and cleaned out
an empty directory. |
| Conversion Error Interceptor |
conversionError |
Adds conversion errors from the ActionContext to the Action's field errors |
| Create Session Interceptor |
createSession |
Create an HttpSession automatically, useful
with certain Interceptors that require a HttpSession to work properly
(like the TokenInterceptor) |
| DebuggingInterceptor |
debugging |
Provides several different debugging screens to provide insight into the data behind the page. |
| Execute and Wait Interceptor |
execAndWait |
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. |
| I18n Interceptor |
i18n |
Remembers the locale selected for a user's session. |
| Logger Interceptor |
logger |
Outputs the name of the Action. |
| Message Store Interceptor |
store |
Store and retrieve action messages / errors / field errors for action that implements ValidationAware interface into session. |
| Model Driven Interceptor |
model-driven |
If the Action implements ModelDriven, pushes the getModel Result onto the Value Stack. |
| Scoped Model Driven Interceptor |
scoped-model-driven |
If the Action implements ScopedModelDriven,
the interceptor retrieves and stores the model from a scope and sets it
on the action calling setModel. |
| 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 |
Provide access to Maps representing HttpServletRequest and HttpServletResponse. |
| Static Parameters Interceptor |
static-params |
Sets the struts.xml defined parameters onto the action. These are the <param> tags that are direct children of the <action> tag. |
| Roles Interceptor |
roles |
Action will only be executed if the user has the correct JAAS role. |
| Timer Interceptor |
timer |
Outputs how long the Action takes to execute (including nested Interceptors and View) |
| Token Interceptor |
token |
Checks for valid token presence in Action, prevents duplicate form submission. |
| Token Session Interceptor |
token-session |
Same as Token Interceptor, but stores 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 are created then it returns the INPUT view. |
| Parameter Filter Interceptor |
N/A |
Removes parameters from the list of those available to Actions |
| Profiling Interceptor |
profiling |
Activate profiling through parameter |
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.
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 but before the Result executes.
thisWillRunFirstInterceptor
thisWillRunNextInterceptor
followedByThisInterceptor
thisWillRunLastInterceptor
MyAction1
MyAction2 (chain)
MyPreResultListener
MyResult (result)
thisWillRunLastInterceptor
followedByThisInterceptor
thisWillRunNextInterceptor
thisWillRunFirstInterceptor