struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wes Wannemacher <>
Subject Re: getting the container (or Configuration/ConfigurationManager) in a non-container-instantiated object
Date Mon, 14 Feb 2011 21:34:20 GMT
Sorry to keep coming back to this guys, but I'm still mulling over this...

If any of you get the chance, can you look over StrutsPrepareFilter,
InitOperations, PrepareOperations and StrutsExecuteFilter and tell me
that a single Dispatcher instance isn't simply shared across all of a
web-app's lifecycle? If I'm right, and the ThreadLocal<Dispatcher>
declaration is pointless, then that will make it pretty easy for me to
subclass one of the filters to make the Dispatcher visible.



On Fri, Feb 11, 2011 at 5:30 PM, Wes Wannemacher <> wrote:
> Rene,
> Thanks for the pointer...
> I guess i still have a few concerns about some of this. I am starting
> to feel like the king of having things that I want to do to struts,
> but never finding the time to do them. If only I could make some money
> w/o being expected to fulfill customer demands ;-)
> I know Don set out a while ago to refactor the Dispatcher and the
> FilterDispatcher and we have Prepare/Execute filters and
> Prepare/Execute operations. Which I think is pretty cool, but one
> thing I still can't seem to find is what the scope of the Dispatcher
> and of some of the objects that the Dispatcher uses. So, it is pretty
> clear that the Dispatcher instance is a Threadlocal, but it looks like
> the Dispatcher is instantiated in the InitOperations. What is unclear
> to me is that it looks like this happens in (looking at the filters,
> not the listener or servlet) in the public void init(FilterConfig) of
> StrutsPrepareFilter, which is run once (right?). So, is a Dispatcher
> singleton simply passed around?
> Looking at InitOperations, it would seem like if this were run for
> each request (which I am pretty sure it is not), then it would
> reinitialize the framework with each request.
> So, my questions are as follows -
> 1. Is this optimal? I could be wrong, but I thought a Dispatcher
> instance was created per-thread... I think I thought so because
> Dispatcher.instance is a threadlocal. None of the other properties in
> the dispatcher are declared static (they are all instance properties).
> I've never really read up much on threadlocals, so if my understanding
> is completely flawed (and showing right now) then I apologize.
> 2. Should we consider refactoring some of this again? I like the
> design, but I feel like we broke out the stuff that should happen
> before execution, then execution itself, but it doesn't feel very
> IoC-ish. *Operations could maybe be servicified so that we could maybe
> make some of this stuff happen as a matter of wiring/configuration
> rather than simply just being broken up.
> 3. If I am right that Dispatcher is a singleton, then my original
> problem is really just a matter of visibility. Am I the only one that
> has ever wanted a reference to the container outside of the framework?
> If the Dispatcher is a singleton, would anyone object to having it in
> the ServletContext as an attribute? I suppose I could create an
> alternate Prepare or Execute filter that inherits from one of the
> originals and make the stuff I want visible.
> I don't know if any of this needs any action right now, but one thing
> that kind of bugs me about struts right now is that in Don's absence,
> I'd like to feel like we, as a team, have a good understanding of how
> the Dispatcher does its magic... I don't want to speak for everyone,
> but right now i feel like I do *not* have a good understanding.
> Thoughts?
> -Wes
> On Fri, Feb 11, 2011 at 5:21 AM, Rene Gielen <> wrote:
>> You need to get hands on the Dispatcher, it hold the correct (even after
>> reloading ...) reference to the Container.
>> While StrutsPrepareFilter initializes the Dispatcher, it does not expose it
>> the the ServletContext. Actually, if you look into
>> StrutsListener.contextInitialized(), you find what you are looking for.
>> Nevertheless, from a short glance it does not look like they play nice
>> together. AFAICS StrutsPrepareFilter should be modified the following way:
>> in the init method, look if ServletContext contains a Dispatcher for
>> attribute key StrutsStatics.SERVLET_DISPATCHER (if the Listener was
>> configured). If found - use it. If not, create it and expose it under the
>> said attribute key
>> We should review if configuring Listener and Filter together do make sense,
>> and if yes, if they need better interaction - especially for
>> prepareOperations.
>> - René
> --
> Wes Wannemacher
> Head Engineer, WanTii, Inc.
> Need Training? Struts, Spring, Maven, Tomcat...
> Ask me for a quote!

Wes Wannemacher

Head Engineer, WanTii, Inc.
Need Training? Struts, Spring, Maven, Tomcat...
Ask me for a quote!

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message