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

Second, Stripes calls ActionResolver.getHandler ( ) to obtain the actual
event handler Method object. If no event name was found in the pre-
vious step, this looks for a method annotated with @DefaultHandler or
for the presence of exactly one event handler method.
The event name is set on the action bean context, and the event handler
Method object is set on the execution context.
BindingAndValidation
At this stage, Stripes binds the request parameters to the corresponding
properties of the action bean, performing validation and type conver-
sion in the process. The work is done by the bind ( ) method of the Action-
BeanPropertyBinder implementation (the default is DefaultActionBeanProp-
ertyBinder ). ValidationErrors that occur are set on the action bean context.
CustomValidation
Custom validation methods (annotated with @ValidationMethod ) are exe-
cuted. If no resolution is returned and the action bean implements Val-
idationErrorHandler , handleValidationErrors ( ) is called.
EventHandling
The action bean's event handler method is executed.
ResolutionExecution
The execute ( ) method is called on the returned Resolution . Changing the
resolution in an interceptor that runs at this stage can be done by
calling setResolution ( ) on the execution context before calling proceed ( ),
not by returning a different resolution from the intercept ( ) method. It's
not possible to change the resolution after this stage, because by then
it's too late—the resolution has already been executed!
There should be a resolution when this stage executes, because if the
resolution is null , nothing happens. No response is given to the request,
and the user's browser is left blank. Dead air. . . .
Unlike all previous life-cycle stages, the ResolutionExecution stage is exe-
cuted regardless of a previous life-cycle stage returning a resolution.
This makes sense—the resolution does have to be executed, after all.