Child pages
  • Message Store Interceptor
Skip to end of metadata
Go to start of metadata

An interceptor to store a ValidationAware action's messages / errors and field errors into HTTP Session, such that it will be retrievable at a later stage. This allows the action's message / errors and field errors to be available longer that just the particular HTTP request.

If no session exists, nothing will be stored and can be retrieved later. In other terms, the application is responsible to open the session.

In the STORE mode, the interceptor will store the ValidationAware action's message / errors and field errors into HTTP session.

In the RETRIEVE mode, the interceptor will retrieve the stored action's message / errors and field errors and put them back into the ValidationAware action.

In the AUTOMATIC mode, the interceptor will always retrieve the stored action's message / errors and field errors and put them back into the [ValidationAware] action, and after Action execution, if the Result is an instance of ServletRedirectResult, the action's message / errors and field errors into automatically be stored in the HTTP session..

The interceptor does nothing in the NONE mode, which is the default.

The operation mode could be switched using:

  1. Setting the interceptor parameter eg.

    xml STORE .... ]]>
  2. Through request parameter allowRequestParameterSwitch must be 'true' which is the default

Parameters

  • allowRequestParameterSwitch - To enable request parameter that could switch the operation mode of this interceptor.
  • requestParameterSwitch - The request parameter that will indicate what mode this interceptor is in.
  • operationMode - The operation mode this interceptor should be in (either STORE, RETRIEVE, AUTOMATIC, or NONE). NONE being the default.

Extending the Interceptor

There is no known extensions.

Examples

xml STORE applicationFailed applicationSuccess.jsp RETRIEVE applicationFailed.jsp ]]>

With the example above, submitApplication.action will have the action messages / errors / field errors stored in the HTTP Session. Later when needed, (in this case, when applicationFailed.action is fired, it will get the action messages / errors / field errors stored in the HTTP Session and put them back into the action.

 

  • No labels

1 Comment

  1. Anonymous

    Where ever possible please avoid using the session as everything is lost when the session expires. It doesn't matter if the authentication is lost with the session as you would normally have to re-authenticate anyway. BUT anything else stored in the session means the previous activity cannot be continued. By avoiding using the session, you can therefore implement deep-linking, arrange to get appropriate behaviour from forward and back keys and fully recover from session time-outs. It makes for a much more natural experience, but the first step is don't use sessions.

    (If you really must use sessions, you can simulate them using most recently used caches in the application context, this allows you to recover from expiry and tune the performance and memory usage of the system, by varying the cache timeout/size)