[
https://issues.apache.org/struts/browse/WW-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_41834
]
jholmes edited comment on WW-1831 at 8/13/07 8:15 PM:
-----------------------------------------------------------
I also ran into this same issue. I fixed the problem by not having my main
action always be in RETRIEVE operation mode. Instead I passed the operation
mode to the main action. I have an example of this below using your original
configuration
<action name="home" class="com.mycompany.action.HomeAction">
<result>home.ftl</result>
<interceptor-ref name="store"/>
<interceptor-ref name="basicStack"/>
</action>
<action name="updateEmail" class="com.mycompany.action.ChangeEmailAction"
method="updateEmail">
<result type="redirect-action">
<param name="actionName">home</param>
<param name="operationMode">RETRIEVE</param>
</result>
<result name="input">editEmail.ftl</result>
<interceptor-ref name="store">
<param name="operationMode">STORE</param>
</interceptor-ref>
<interceptor-ref name="validationStack"/>
</action>
Notice that the operation mode of RETRIEVE is passed as parameter on the
redirect-action result.
was (Author: jholmes):
I also ran into this same issue. I fixed the problem by not having my main
action always be in RETRIEVE operation mode. Instead I passed the operation
mode to the main action. I have an example of this below using your original
configuration
<action name="home" class="com.mycompany.action.HomeAction">
<result>home.ftl</result>
<interceptor-ref name="store"/>
<interceptor-ref name="basicStack"/>
</action>
<action name="updateEmail" class="com.mycompany.action.ChangeEmailAction"
method="updateEmail">
<result type="redirect-action">
<param name="actionName">home</param>
<param name="operationMode">RETRIEVE</param>
</result>
<result name="input">editEmail.ftl</result>
<interceptor-ref name="store">
<param name="operationMode">STORE</param>
</interceptor-ref>
<interceptor-ref name="validationStack"/>
</action>
Notice that the operation mode of RETRIEVE is passed as parameter on the
redirect-action result.
I still believe this should be fixed though and I will work on that.
> 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, 2.0.7, 2.0.8, 2.0.9
> Reporter: Jasper Rosenberg
> Assignee: James Holmes
> Fix For: Future
>
>
> 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.
