Chris, That is exactly what I see.
Does anyone have a problem with changing the declaration of the Dispatcher instance, and providing some visibility of the Dispatcher instance (such as shoving it into the ApplicationContext)? -Wes On Tue, Feb 15, 2011 at 8:48 AM, musomesa <musom...@aol.com> wrote: > 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 > ThreadLocal<Dispatcher> > 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 (?) > > Cheers > Chris > > 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<w...@wantii.com> 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<gie...@it-neering.net> >>> 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: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > -- Wes Wannemacher Head Engineer, WanTii, Inc. Need Training? Struts, Spring, Maven, Tomcat... Ask me for a quote! --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
