Carsten Ziegeler a écrit :
>
> Has noone else an opinion on this topic?
>
We do use ThreadLocals in our apps to store the session and user
principal. This avoids passing it as a parameter in each and every
method.
But this can raise security issues : you have to be sure that code that
is called after the ThreadLocal's value is set has to know about it and
doesn't change it if it doesn't have to.
> Carsten
>
> Open Source Group sunShine - b:Integrated
> ================================================================
> Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> www.sundn.de mailto: [EMAIL PROTECTED]
> ================================================================
>
> > Carsten Ziegeler wrote:
> >
> > Hi,
> >
> > looking at some problems I am wondering if it is "legal"
> > to use the ThreadLocal class.
> >
> > I see some use cases for it:
> >
> > Use Case 1:
> > Marcus Crafter recently asked if it is possible to
> > have the SourceResolver available in components
> > which are not SitemapComponents and/or if it is
> > possible to have it available at earlier stages
> > than the setup() method, e.g. in the configure()
> > method.
Is the SourceResolver available at configure() time ?
> >
> > Use Case 2:
> > Logging. The current information logged contains
> > only the thread id and time information. If the
> > logger (or formatter) has access to the current
> > environment or objectModel it could print out
> > more information ,e.g. the request uri or the
> > ip address etc.
Maybe the ContextStack class in LogKit can help in this. I never used
it, but maybe someone has some experience with it ?
> >
> > As it is not possible to pass the SourceResolver
> > or the objectModel to the components via the
> > methods called, there has to be another way.
> > (E.g. we can't change the signature of the
> > configure() method to include the SourceResolver
> > as it is a standardized Avalon interface - which
> > is very good).
> >
> > So I though of creating a defined ThreadLocal
> > variable which contains either the environment
> > or the objectModel or the SourceResolver or
> > whatever needed.
> >
> > We could either make this variable available
> > via a static variable of some class, e.g.
> > the Cocoon class or we could hide the
> > existence of the ThreadLocal instance and
> > create an avalon component which accesses
> > this ThreadLocal variable, so the avalon
> > component must be looked up and offers
> > some get methods to retrieve the
> > information.
> >
IMHO, you will sooner or later need another ThreadLocal to know the
ComponentManager ;)
> > What are your thoughts? Comments? Ideas?
> >
> >
> > Carsten
> >
> > Open Source Group sunShine - b:Integrated
> > ================================================================
> > Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> > www.sundn.de mailto: [EMAIL PROTECTED]
> > ================================================================
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
