Loading...

dev@struts.apache.org

[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: getting the container (or Configuration/ConfigurationManager) in a non-container-instantiated object Wes Wannemacher Fri Feb 11 17:00:41 2011

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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]