You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by ppm10103 <pp...@163.com> on 2013/04/23 11:06:53 UTC
why Struts2 Dispatcher instance bind to ThreadLocal
The Dispatcher will have only one instance,
it bind to ThreadLocal is for what?
thanks.
Re: Re: why Struts2 Dispatcher instance bind to ThreadLocal
Posted by Lukasz Lenart <lu...@apache.org>.
2013/4/26 Ken McWilliams <ke...@gmail.com>:
> 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?
E.g. Sitemesh integration, there were problems with that before split
into two filters
http://struts.apache.org/development/2.x/docs/sitemesh-plugin.html
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
Re: Re: why Struts2 Dispatcher instance bind to ThreadLocal
Posted by Ken McWilliams <ke...@gmail.com>.
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 <lu...@apache.org>wrote:
> Thanks, it's much clear now how StrutsPrepare and StrutsExecute cooperate
> :-)
>
> 2013/4/25 Don Brown <do...@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 <lu...@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 <do...@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 <pp...@163.com> wrote:
> >> >>
> >> >>
> >> >> At 2013-04-24 03:44:22,"Lukasz Lenart" <lu...@apache.org>
> wrote:
> >> >>
> >> >> >2013/4/23 ppm10103 <pp...@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
>
>
Re: Re: why Struts2 Dispatcher instance bind to ThreadLocal
Posted by Lukasz Lenart <lu...@apache.org>.
Thanks, it's much clear now how StrutsPrepare and StrutsExecute cooperate :-)
2013/4/25 Don Brown <do...@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 <lu...@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 <do...@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 <pp...@163.com> wrote:
>> >>
>> >>
>> >> At 2013-04-24 03:44:22,"Lukasz Lenart" <lu...@apache.org> wrote:
>> >>
>> >> >2013/4/23 ppm10103 <pp...@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
Re: Re: why Struts2 Dispatcher instance bind to ThreadLocal
Posted by Don Brown <do...@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 <lu...@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 <do...@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 <pp...@163.com> wrote:
> >>
> >>
> >> At 2013-04-24 03:44:22,"Lukasz Lenart" <lu...@apache.org> wrote:
> >>
> >> >2013/4/23 ppm10103 <pp...@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?
> >
> >
>
Re: Re: why Struts2 Dispatcher instance bind to ThreadLocal
Posted by Lukasz Lenart <lu...@apache.org>.
Thanks MrDon :-)
What you mean by "two filters"?
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
2013/4/24 Don Brown <do...@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 <pp...@163.com> wrote:
>>
>>
>> At 2013-04-24 03:44:22,"Lukasz Lenart" <lu...@apache.org> wrote:
>>
>> >2013/4/23 ppm10103 <pp...@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
Re: Re: why Struts2 Dispatcher instance bind to ThreadLocal
Posted by Don Brown <do...@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 <pp...@163.com> wrote:
>
> At 2013-04-24 03:44:22,"Lukasz Lenart" <lu...@apache.org> wrote:
>
> >2013/4/23 ppm10103 <pp...@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?
Re:Re: why Struts2 Dispatcher instance bind to ThreadLocal
Posted by ppm10103 <pp...@163.com>.
At 2013-04-24 03:44:22,"Lukasz Lenart" <lu...@apache.org> wrote:
>2013/4/23 ppm10103 <pp...@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?
Re: why Struts2 Dispatcher instance bind to ThreadLocal
Posted by Lukasz Lenart <lu...@apache.org>.
2013/4/23 ppm10103 <pp...@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