At first glance that seems like a *great* catch.
--- Jeromy Evans <[EMAIL PROTECTED]> wrote:
> I'm investigating some of issues related to the s:action tag. This tag
> sets up a new context and ActionInvocation and invokes the action and
> result correctly. The problem is that within that process the
> 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 a
> few more that got me started down this path).
>
> I'm not sure how to fix this. If actions can rely on the ThreadLocal
> ActionContext (they do), the current invocation needs to be there, but
> the invocation has no sensible way to know that it should restore the
> previous state. I don't want to pass more flags in from the action tag.
>
> Has anyone got some suggestions on a tidy way to resolve this? Removing
> the ThreadLocals would be nice.
My naïve reaction would be to put it on a stack, since we're talking nested
contexts, and set the thread local from it. But I can't even find that code
right now :/
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
