Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3B5C4ADB.2609F38D@anyware-tech.com>
Date: Mon, 23 Jul 2001 18:03:39 +0200
From: Sylvain Wallez <sylvain.wallez@anyware-tech.com>
Organization: Anyware Technologies
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: AW: [C2]: Using ThreadLocal?
References: <GMEBIBHGAOFGJCDPJANDCEFGCGAA.cziegeler@sundn.de>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit


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: cziegeler@sundn.de
> ================================================================
> 
> > 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: cziegeler@sundn.de
> > ================================================================

-- 
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org