[
https://issues.apache.org/struts/browse/WW-2611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeromy Evans updated WW-2611:
-----------------------------
Description:
This tag sets up a new context and ActionInvocation and invokes the action and
result correctly. The problem is that within that process XWork's
DefaultActionInvocation replaces the ActionInvocation in the ThreadLocal
ActionContext with the tag's own invocation:
// Setting this so that other classes, like object factories, can use
the ActionProxy and other
// contextual information to operate
ActionContext actionContext = ActionContext.getContext();
if(actionContext != null) {
actionContext.setActionInvocation(this);
}
The effect is that after completion of the tag, the ActionInvocation in the
ThreadLocal ActionContext still references the tag's temporary invocation
instead of the "parent" action's invocation. From that point, anything can
happen, and does (WW-2079, WW-2290, WW-2599 and TagUtils.buildNamespace).
I'm not sure how to fix this. Placing the ActionInvocation into a ThreadLocal
goes against the the stack-based architecture of Struts2.
was:
This tag sets up a new context and ActionInvocation and invokes the action and
result correctly. The problem is that within that process XWork's
DefaultActionInvocation replaces the ActionInvocation in the ThreadLocal
ActionContext with the tag's own invocation:
// Setting this so that other classes, like object factories, can use
the ActionProxy and other
// contextual information to operate
ActionContext actionContext = ActionContext.getContext();
if(actionContext != null) {
actionContext.setActionInvocation(this);
}
The effect is that after completion of the tag, the ActionInvocation in the
ThreadLocal ActionContext still references the tag's temporary invocation
instead of the "parent" action's invocation. From that point, anything can
happen, and does (WW-2079, WW-2290, WW-2599 and TagUtils.buildNamespace).
I'm not sure how to fix this. Placing the ActionInvocation into a ThreadLocal
goes against the the stack-based architecture Struts2.
Summary: s:action tag leaves invalid ActionInvocation in threadlocal
ActionContext (was: s:action tag leaves invalidate ActionInvocation in
threadlocal ActionContext)
> s:action tag leaves invalid ActionInvocation in threadlocal ActionContext
> -------------------------------------------------------------------------
>
> Key: WW-2611
> URL: https://issues.apache.org/struts/browse/WW-2611
> Project: Struts 2
> Issue Type: Bug
> Affects Versions: 2.0.11.1, 2.1.1
> Reporter: Jeromy Evans
>
> This tag sets up a new context and ActionInvocation and invokes the action
> and result correctly. The problem is that within that process XWork's
> DefaultActionInvocation replaces the ActionInvocation in the ThreadLocal
> ActionContext with the tag's own invocation:
> // Setting this so that other classes, like object factories, can use
> the ActionProxy and other
> // contextual information to operate
> ActionContext actionContext = ActionContext.getContext();
> if(actionContext != null) {
> actionContext.setActionInvocation(this);
> }
> The effect is that after completion of the tag, the ActionInvocation in the
> ThreadLocal ActionContext still references the tag's temporary invocation
> instead of the "parent" action's invocation. From that point, anything can
> happen, and does (WW-2079, WW-2290, WW-2599 and TagUtils.buildNamespace).
> I'm not sure how to fix this. Placing the ActionInvocation into a
> ThreadLocal goes against the the stack-based architecture of Struts2.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
