Stripes - Action Bean/Request Life Cycle

Stage0: Pre-processing by the Stripes filter

Firstly it "hides" the current Configuration somewhere, so that anywhere in the application the Configuration can be retrieved by calling StripesFilter.getConfiguration()

Secondly it resolves the Locale that should be used for the current request. It does this by invoking the configured LocalePicker.

Thirdly it wraps the HttpServletRequest with a StripesRequestWrapper. The wrapper ensures that HttpServletRequest.getLocale() always returns the picked Locale.

At this point the flow of control could flow directly to a JSP. If the request is for an ActionBean event, then we continue on to the Stripes DispatcherServlet.

Stage1: Resloving the Action Bean

Firstly the DispatcherServlet fetches the configured ActionBeanContextFactory and uses it to manufacture an ActionBeanContext. The DefaultActionBeanContextFactory looks for a configured class name, and if none is found, creates a new ActionBeanContext.

The DispatcherServlet then fetches the configured ActionResolver and uses it to resolve the appropriate ActionBean instance. The default ActionResolver is the NameBasedActionResolver.

Stage2: Handler Resolution

DispatcherServlet uses the ActionResolver to determine the name of the event submitted. If there was no identifiable event name then the ActionResolver is asked for the @DefaultHandler method, otherwise it is asked for the method which handles the named event.

The event name is then set on the ActionBeanContext.

Stage3: Binding & Field validation

The process of binding and validation, while driven by Stripes, allows the ActionBean author to assert a certain amount of control.

• @Validate and @ValidateNestedProperties allow ActionBeans to specify validations to be run onproperties

• @DontValidate allows individual handler methods to request that validation be by-passed

• ValidationMethod allows ActionBeans to plug in custom validation logic

• ValidationErrorHandler allows ActionBeans to intercept validation errors and decide what happens next


Stage4: Custom Validation

Validation methods may be specified to run only when no errors have been generated so far, or always.An application level default exists and can be configured; if not configured the default is not to run validation methods when errors exist.

When errors are discovered during validation and the ActionBean implements ValidationErrorHandler the handleValidationErrors(errors) method will be invoked. In this method bean authors may manipulate the collection of errors (perhaps emptying it, which has significant implications) and/or return an alternative Resolution. If a Resolution is returned it is executed immediatley.


Stage5: Executing the Action Bean

If there is no validation errors, the DispatcherServlet will invoke the Handler method on the Action Bean.

Handler method should return a resolution,If ActionBean returns a non-null resolution the DispatcherServlet will call its execute() method to complete the request.