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 -> [EMAIL PROTECTED]
managing partners, inc. -> http://www.managingpartners.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
