Understanding Interceptors
Interceptors allow you to define code to be executed before and/or
after the execution of an Action method. (The "Filter" pattern.)
There are many, many use cases for Interceptors, including validation, property population, security, logging, and profiling.
Interceptors can be chained together to create an Interceptor "Stack".
If an action neeeds to check the client's credentials, log the action, and time the action, all of these routines, and more, could be made part of the same Interceptor Stack.
Interceptors are implemented as Java classes, so each Interceptor has a class name.
To make it easier to reference Interceptors, each class can be registered with the framework and given a unique, simpler name.
Individual Interceptors and Interceptors Stacks can be "mixed and matched" in any order when defining an Interceptor Stack.
The framework will invoke each Interceptor on the stack in the order it is defined.
More Detail
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.
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.
There are many, many use cases for Interceptors, including validation, property population, security, logging, and profiling.
| Validation | Examine input for correctness |
|---|---|
| Property Population | Transfer and convert input to object properties |
| Logging | Journal details regarding each action |
| Profiling | Time action throughput, looking for performance bottlenecks |
Interceptors can be chained together to create an Interceptor "Stack".
If an action neeeds to check the client's credentials, log the action, and time the action, all of these routines, and more, could be made part of the same Interceptor Stack.
Interceptors are implemented as Java classes, so each Interceptor has a class name.
To make it easier to reference Interceptors, each class can be registered with the framework and given a unique, simpler name.
Individual Interceptors and Interceptors Stacks can be "mixed and matched" in any order when defining an Interceptor Stack.
The framework will invoke each Interceptor on the stack in the order it is defined.
More Detail
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.
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
struts.xml
<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="redirectAction">/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.
struts.xml
<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="redirectAction">/secure/home</result></action></package> |