Thanks, it's much clear now how StrutsPrepare and StrutsExecute cooperate :-)
2013/4/25 Don Brown <donald.br...@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 <lukaszlen...@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.br...@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 <ppm10...@163.com> wrote: >> >> >> >> >> >> At 2013-04-24 03:44:22,"Lukasz Lenart" <lukaszlen...@apache.org> wrote: >> >> >> >> >2013/4/23 ppm10103 <ppm10...@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-unsubscr...@struts.apache.org >> >> >For additional commands, e-mail: dev-h...@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-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
