struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ken McWilliams <ken.mcwilli...@gmail.com>
Subject Re: Re: why Struts2 Dispatcher instance bind to ThreadLocal
Date Fri, 26 Apr 2013 20:21:54 GMT
I still don't understand what the use case isxe for the two filters. In the
StrutsPrepareAndExecuteFilter the source of both the Prepare and Execute
filters are clearly concatenated.

What kind of 3rd party functionality will need to grab onto struts2
resources created via prepare and before execute?

Seems like interceptors could cover most of the ground. What is left? Why
would it be more convenient to take this path?




On Fri, Apr 26, 2013 at 12:33 AM, Lukasz Lenart <lukaszlenart@apache.org>wrote:

> Thanks, it's much clear now how StrutsPrepare and StrutsExecute cooperate
> :-)
>
> 2013/4/25 Don Brown <donald.brown@gmail.com>:
> > Two servlet filters - one to do 95% of the work, the second to cleanup
> any
> > thread locals.
> >
> > Don
> >
> >
> > On Thu, Apr 25, 2013 at 1:06 AM, Lukasz Lenart <lukaszlenart@apache.org>
> > wrote:
> >>
> >> Thanks MrDon :-)
> >>
> >> What you mean by "two filters"?
> >>
> >>
> >> Regards
> >> --
> >> Łukasz
> >> + 48 606 323 122 http://www.lenart.org.pl/
> >>
> >> 2013/4/24 Don Brown <donald.brown@gmail.com>:
> >> > This all goes way back to the days of WebWork and how much they loved
> >> > statics.  WebWork basically used static singletons for everything,
> >> > causing
> >> > a) a really complicated startup order and b) the ability to only run
> one
> >> > instance of the framework.  In those days (and perhaps still?) there
> >> > wasn't
> >> > just one filter but at least two to allow proper thread-local cleanup,
> >> > because what wasn't accessed statically was accessed statically using
> >> > thread
> >> > locals as the means (ActionContext.getContext() for example).
> >> >
> >> > Therefore, with two filters that contain state that needs to be
> accessed
> >> > statically, we were limited to threadlocals to track that state.
>  When I
> >> > was
> >> > working on it, I got it to the point that most statics were gone and
> we
> >> > had
> >> > a decent injection system to avoid all the static accessors, but they
> >> > were
> >> > still there in case you needed them.  I don't know what the code is
> like
> >> > now, but it sounds like perhaps it still hasn't completely gotten away
> >> > from
> >> > statics and threadlocals.
> >> >
> >> > As a side note, back then (2008?) we did some profiling and found that
> >> > actually all the thread locals were eating up a bunch of time in the
> >> > request, so it is more than just a general "icky" sense that should
> >> > drive
> >> > their removal.
> >> >
> >> > Again, my knowledge is pretty dated, but that's where things came
> from.
> >> >
> >> > Don
> >> >
> >> >
> >> > On Tue, Apr 23, 2013 at 7:40 PM, ppm10103 <ppm10103@163.com> wrote:
> >> >>
> >> >>
> >> >> At 2013-04-24 03:44:22,"Lukasz Lenart" <lukaszlenart@apache.org>
> wrote:
> >> >>
> >> >> >2013/4/23 ppm10103 <ppm10103@163.com>:
> >> >> >> The Dispatcher  will have only one instance,
> >> >> >> it bind to ThreadLocal  is for what?
> >> >> >
> >> >> >For thread safety, then you can access Dispatcher from a thread
> >> >> >without synchronisation. That's my opinion :-)
> >> >> >
> >> >> >
> >> >> >Regards
> >> >> >--
> >> >> >Łukasz
> >> >> >+ 48 606 323 122 http://www.lenart.org.pl/
> >> >> >
> >> >>
> >---------------------------------------------------------------------
> >> >> >To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> >> >For additional commands, e-mail: dev-help@struts.apache.org
> >> >> >
> >> >>
> >> >> Thanks for your help,but I look into the sourcecode ,the Dispatcher
> >> >> will
> >> >> only be one instance,
> >> >> so even put it in the ThreadLocal,every thead alse access the same
> >> >> Dispatcher  instance,
> >> >> so I think it's not for thread safe,so I still want to konw it's for
> >> >> what?
> >> >
> >> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message