<action name="myAction" class="myActionClass"> <interceptor-ref name="exception"/> <interceptor-ref name="alias"/> <interceptor-ref name="params"/> <interceptor-ref name="servletConfig"/> <interceptor-ref name="prepare"/> <interceptor-ref name="i18n"/> <interceptor-ref name="chain"/> <interceptor-ref name="modelDriven"/> <interceptor-ref name="fileUpload"/> <interceptor-ref name="staticParams"/> <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 'interceptor-ref' refer to an existing interceptor-stack, namely defaultStack in this example, and override the validator and workflow interceptor excludeMethods typically in this case. 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. Essetially it is as follows :-
<interceptor-name>.<parameter-name>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. Nested Interceptor param overriding 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 |
<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>@author Jason Carreira @author tmjee @version $Date$ $Id$
Represents an enabled {@linkplain javax.interceptor interceptor}.
@author Gavin King @author Pete Muir @author David Allen @param < T> the interceptor bean classPortletInterceptor is an object that is called prior and after {@link Portlet#service()} is called
@author Herve Tchepannou
Interface for classes which wish to intercept the processing of a request at various stages in the Stripes lifecycle. To denote the {@link LifecycleStage} (or stages) atwhich an interceptor should run, the class should be marked with an {@link Intercepts}annotation declaring one or more lifecycle stages.
{@code Interceptors} execute around the intercepted lifecycle stage. Assuming forsimplicity's sake that a single interceptor is configured, any code in the {@link #intercept(ExecutionContext)} method prior to calling {@code context.proceed()} willbe executed immediately prior to the lifecycle code. Any code after calling {@code context.proceed()} will be executed immediately after the lifecycle code. For examplethe following implementation would print out a message before and after validation and binding occur:
{@literal @}Intercepts(LifecycleStage.BindingAndValidation) public class NoisyInterceptor implements Interceptor { public Resolution intercept(ExecutionContext context) { System.out.println("Before validation and binding!"); Resolution r = context.proceed(); System.out.println("After validation and binding!"); return r; } } Interceptors can, in addition to adding behaviour, divert the flow of execution. They do this by returning a {@link Resolution}. If an interceptor returns a Resolution Stripes will abort processing of the current request and immediately execute the Resolution.
Interceptor developers must be careful to ensure that interceptors are well behaved. To continue normal processing interceptors must invoke {@code context.proceed()}. Since a given interceptor may be part of a stack of interceptors, or the lifecycle code may return a resolution, the interceptor must return the Resolution produced by {@code context.proceed()}unless it explicitly wishes to alter the flow of execution.
Interceptors gain access to information about the current execution environment through the {@link ExecutionContext}. Through this they can access the ActionBean, the handler Method, the lifecycle stage etc. Care must be taken to ensure that information is available before using it. For example interceptors which execute around ActionBeanResolution will not have access to the current ActionBean until after calling context.proceed() and will not have access to the event name or handler method at all (HandlerResolution occurs after ActionBeanResolution).
Optionally, Interceptor classes may implement the {@link net.sourceforge.stripes.config.ConfigurableComponent} interface. If implemented,the Interceptor will have it's {@code init(Configuration)} method called after instantiationand before being placed into service.
Interceptors are located by Stripes through it's {@link net.sourceforge.stripes.config.Configuration}. To configure interceptors you can either implement your own Configuration (probably by subclassing {@link net.sourceforge.stripes.config.RuntimeConfiguration}), or more likely by listing out the interceptors desired in the web.xml as specified in the documentation for {@link net.sourceforge.stripes.config.RuntimeConfiguration#initInterceptors()}.
@author Tim Fennell @since Stripes 1.3service() method. Note that Interceptors may be associated with any type of Container, so it is up to the Interceptor implementation to avoid class cast exceptions. An Interceptor can refuse to be associated with a particular Container by returning IllegalArgumentException to the setContainer() method. The Container with which an Interceptor is associated must guarantee that the postService() method will be called if the preService() method was called, even in the face of exceptions.
@author Craig R. McClanahan
@version $Revision: 1.4 $ $Date: 2000/01/24 08:31:30 $
Interface for implementers of interception.
Each implementor must satisfy, that in the {@link #intercept(InvocationContext)} method body will be called at leastonce method from current context {@link InvocationContext#invoke()}.
@author Jan Papousek @author Juraj Huska20011219 marc fleury:
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |