You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@sundn.de> on 2001/07/19 11:01:33 UTC
[C2]: Using ThreadLocal?
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.
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.
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.
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
================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [C2]: Using ThreadLocal?
Posted by Carsten Ziegeler <cz...@sundn.de>.
Thanks for your answer Peter.
So I suggest that the servlet defines a ThreadLocal variable
which can then be used by an own avalon formatter to format
the output of the log.
I think the servlet is responsible for this as the logger,
the targets and the formatter are all set there.
Carsten
> Peter Royal wrote:
>
> At 03:45 PM 7/23/2001 +0200, you wrote:
> >Has noone else an opinion on this topic?
>
> I have a quasi-related one :) I hesitated to send it initially as
> I wasn't
> sure to the relevance.
>
> > > 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.
>
> We use avalon over here for the other 1/2 of our application that the c2
> front-end talks to. I was thinking about hiding a ThreadLocal variable
> inside of a component to store session information. In our case,
> any given
> thread that is doing work for a user is always associated with a single
> session, and rather than pass a session ID around in all of our method
> calls, why not just have a component that always returns the
> proper session.
>
> I think using ThreadLocal's to solve some problems might be a good idea,
> mainly your #2 suggestion, logging. The more information that can
> be saved
> in the log when an error occurs, the better. It has been our experience
> that end users are very bad about reporting bugs, and then even
> if they do
> report then, getting information about the context in which the bug
> occurred can be very difficult.
>
> just my .02
> -pete
>
> --
> peter royal -> proyal@managingpartners.com
> managing partners, inc. -> http://www.managingpartners.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: [C2]: Using ThreadLocal?
Posted by Peter Royal <pr...@managingpartners.com>.
At 03:45 PM 7/23/2001 +0200, you wrote:
>Has noone else an opinion on this topic?
I have a quasi-related one :) I hesitated to send it initially as I wasn't
sure to the relevance.
> > 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.
We use avalon over here for the other 1/2 of our application that the c2
front-end talks to. I was thinking about hiding a ThreadLocal variable
inside of a component to store session information. In our case, any given
thread that is doing work for a user is always associated with a single
session, and rather than pass a session ID around in all of our method
calls, why not just have a component that always returns the proper session.
I think using ThreadLocal's to solve some problems might be a good idea,
mainly your #2 suggestion, logging. The more information that can be saved
in the log when an error occurs, the better. It has been our experience
that end users are very bad about reporting bugs, and then even if they do
report then, getting information about the context in which the bug
occurred can be very difficult.
just my .02
-pete
--
peter royal -> proyal@managingpartners.com
managing partners, inc. -> http://www.managingpartners.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: [C2]: Using ThreadLocal?
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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
AW: [C2]: Using ThreadLocal?
Posted by Carsten Ziegeler <cz...@sundn.de>.
Has noone else an opinion on this topic?
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.
>
> 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.
>
> 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.
>
> 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
> ================================================================
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org