Common use case for stranded messages in MessageStoreInterceptor 
-----------------------------------------------------------------

                 Key: WW-1831
                 URL: https://issues.apache.org/struts/browse/WW-1831
             Project: Struts 2
          Issue Type: Improvement
          Components: Interceptors
    Affects Versions: 2.0.6
            Reporter: Jasper Rosenberg


I have what I think would be a pretty common use case for the 
MessageStoreInterceptor where, under some circumstances, messages could be left 
in the session, taking up memory unncessarily.

The sample use case is that when someone submits an email change, on success I 
want to redirect them back to their home action, passing any messages (i.e. 
"Your email has been successfully changed") along for display.  I used to do 
this with action chaining which worked but was sub-optimal since the user would 
end up back at their home page with an url like "updateEmail.action" rather 
than "home.action".

MessageStoreInterceptor seems like the right solution for this case as now I 
can have the updateEmail store the message, redirect to the home page, and then 
have home page retrieve it:

<action name="home"
        class="com.mycompany.action.HomeAction">
    <result>home.ftl</result>
    <interceptor-ref name="store">
        <param name="operationMode">RETRIEVE</param>
    </interceptor-ref>
    <interceptor-ref name="basicStack"/>
</action>

<action name="updateEmail"
        class="com.mycompany.action.ChangeEmailAction" method="updateEmail">
    <result type="redirect-action">
        <param name="actionName">home</param>
    </result>
    <result name="input">editEmail.ftl</result>
    <interceptor-ref name="store">
        <param name="operationMode">STORE</param>
    </interceptor-ref>                
    <interceptor-ref name="validationStack"/>
</action>

The problem is the case when the result of updateEmail is "input" rather than 
"success".  In this case, I just redisplay the change email form, but any 
validation errors will have been stored in the session.  If the user then 
navigates away or closes the browser, these messages will be stranded in the 
session.

I think there is a pretty simple fix for this:

In MessageStoreInterceptor.before(), simply move the lines:

            session.remove(actionErrorsSessionKey);
            session.remove(actionMessagesSessionKey);
            session.remove(fieldErrorsSessionKey);

out of the nested ifs so that they are always the last operations in the method.

This will handle any case other than a redirect/chain to an action that doesn't 
have the interceptor at all (which can't be helped).

Another option to this is to explictly support an additional parameter for the 
Interceptor like "clearStoredMessages" which defaults to false, but if true 
always calls the session.remove()s at the end of the before().

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to