struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From musomesa <>
Subject Re: getting the container (or Configuration/ConfigurationManager) in a non-container-instantiated object
Date Tue, 15 Feb 2011 13:48:41 GMT
Hi Wes,
       Here is what I see:

StrutsPrepareFilter init method:
     creates InitOperations init
         calls init.initDispatcher
             initDispatcher calls createDispatcher
                 which returns a new Dispatcher
The new Dispatcher is given to PrepareOperations's constructor which 
store is in its Dispatcher field

StrutsPrepareFilter doFilter method:
     calls  prepare.assignDispatcherToThread()
     which calls Dispatcher.setInstance(dispatcher)
         here dispatcher is the field created as StrutsPrepareFilter's 
init method ran
     It (the dispatcher) is stored in the ThreadLocal field of Dispatcher


In the private Dispatcher field of PrepareOperations is the same as the 
in the Dispatcher. I think the intent was visibility so the that the 
client thread can access it
but then there can't be any thread safety issues as it is already shared 
so it could as well
be static (?)


On 2/14/2011 4:34 PM, Wes Wannemacher wrote:
> 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.
> Thanks!
> -Wes
> 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!

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

View raw message