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