You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Joe Germuska <Jo...@Germuska.com> on 2005/09/23 19:07:57 UTC
ThreadLocal ActionContext and thread model of
requestDispatcher.forward
I was experimenting with a local subclass of ActionContext which
added itself to a ThreadLocal in the constructor, so that I could in
theory get access to the ActionContext from classes which don't get
it passed in. (I wanted to use it in a TilesController, for example,
or maybe in a JSTL function.)
Anyway, my view-level code isn't seeing the value, so I guess that
means that requestDispatcher.forward() spawns a new thread. This
makes sense, but I hadn't thought of it that way.
The problem here is that making the ActionContext available to the
View is problematic, since ActionContext.release() is going to be
called asynchronously from the view processing -- so even putting the
context in the request is problematic.
That said, I've maintained a design for my subclasses of
ActionContext so that you can always safely make one as a wrapper to
the ServletContext, Request, and Response -- the ActionContext itself
has no state. This works pretty well, and I was able to do it in the
TilesController and also in a DWR remote object (and DWR doesn't even
use Struts for request processing). Perhaps we should just document
this fact and advise people accordingly -- "if you extend
ActionContextBase, be careful not to add any instance variables, or
you may lose this functionality.)"
Just thought I'd share...
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ThreadLocal ActionContext and thread model of
requestDispatcher.forward
Posted by Joe Germuska <Jo...@Germuska.com>.
>Anyway, my view-level code isn't seeing the value, so I guess that
>> means that requestDispatcher.forward() spawns a new thread. This
>> makes sense, but I hadn't thought of it that way.
>
>
>Forwarding had better *not* create a new thread ... that would violate the
>servlet spec. Something else must be going on.
uh, yeah. my bad. I was initializing the ThreadLocal in one
constructor but not the other, and I picked the wrong one.
OK then. I'm probably going to let this stew for a while in my local
code, unless people really want to see this in the core. Last time
we just stalled wondering which class should hold the ThreadLocal,
since unlike FacesContext, ActionContext is an interface.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ThreadLocal ActionContext and thread model of requestDispatcher.forward
Posted by Craig McClanahan <cr...@apache.org>.
On 9/23/05, Joe Germuska <Jo...@germuska.com> wrote:
>
> I was experimenting with a local subclass of ActionContext which
> added itself to a ThreadLocal in the constructor, so that I could in
> theory get access to the ActionContext from classes which don't get
> it passed in. (I wanted to use it in a TilesController, for example,
> or maybe in a JSTL function.)
JSF does the same kind of thing ... you can call the static method
FacesContext.getCurrentInstance() to get the FacesContext instance for the
current request. Internally, its stored in a ThreadLocal maintained by the
JSF implementation.
Anyway, my view-level code isn't seeing the value, so I guess that
> means that requestDispatcher.forward() spawns a new thread. This
> makes sense, but I hadn't thought of it that way.
Forwarding had better *not* create a new thread ... that would violate the
servlet spec. Something else must be going on.
Craig
The problem here is that making the ActionContext available to the
> View is problematic, since ActionContext.release() is going to be
> called asynchronously from the view processing -- so even putting the
> context in the request is problematic.
>
> That said, I've maintained a design for my subclasses of
> ActionContext so that you can always safely make one as a wrapper to
> the ServletContext, Request, and Response -- the ActionContext itself
> has no state. This works pretty well, and I was able to do it in the
> TilesController and also in a DWR remote object (and DWR doesn't even
> use Struts for request processing). Perhaps we should just document
> this fact and advise people accordingly -- "if you extend
> ActionContextBase, be careful not to add any instance variables, or
> you may lose this functionality.)"
>
> Just thought I'd share...
>
> Joe
>
> --
> Joe Germuska
> Joe@Germuska.com
> http://blog.germuska.com
> "Narrow minds are weapons made for mass destruction" -The Ex
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>