Tapping into Stripes - Stripes...and Java Web Development is Fun Again - page 286

on the other hand, we want to interrupt the flow, we would return a
different resolution from intercept ( ).
As we are writing code in the intercept ( ) method, the ExecutionContext
object gives us information we can use as we want, including the
following:
• The current life-cycle stage, which is useful when we're intercept-
ing more than one stage
• The action bean context, which is available at every stage
• The action bean, which becomes available after the ActionBeanRes-
olution stage
• The event handler Method object, available after the HandlerReso-
lution stage; at this point, we can also retrieve the event handler
name by calling getEventName ( ) on the action bean context
• The ValidationErrors from the action bean context, after the Bindin-
gAndValidation stage
• The current Resolution , which is normally null until either a valida-
tion error occurs or the EventHandling stage has completed
If we also need configuration information, we can have our intercep-
tor class implement the ConfigurableComponent interface. Stripes will
automatically call the init(Configuration) after creating an instance of our
interceptor.
In What Order Are Interceptors Executed?
If we have more than one interceptor that runs on the same life-cycle
stage, the order in which they are executed may or may not be impor-
tant to us. If the order matters, we must know that interceptors loaded
by the Stripes extension packages mechanism are executed in no guar-
anteed order. We're not out of luck, though. To control the order, we
move our interceptors to a nonextension package (or annotate them
with @DontAutoLoad ) and configure them in web.xml file, in the desired
order:
<filter>
<filter-name> StripesFilter </filter-name>
<filter-class>
net.sourceforge.stripes.controller.StripesFilter
</filter-class>
<!-- other init params... -->
<init-param>
<param-name> Interceptor.Classes </param-name>
<param-value>