commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: [logging] JCL2.0 design - Architecture
Date Sat, 25 Feb 2006 17:56:33 GMT
On Mon, 2006-02-20 at 13:31 +0100, Remy Maucherat wrote:
> On 2/20/06, Simon Kitching <skitching@apache.org> wrote:

<snip>

> > > - Please continue providing support for using the TCCL (as the TCCL -
> > > or similar - is used in most JNDI impls, doing otherwise is a bit
> > > redudant as far as I am concerned, and JNDI access is most likely
> > > slower).
> >
> > I'd be very interested in your opinion about the safety/stability of
> > TCCL-based solutions. I was looking at Sun's java bugtracker recently
> > and found an issue raised by JBoss stating that they wanted some
> > classloader synchronisation code changed as Marc Fleury has been
> > experimenting with "dependency-based classloaders that aren't tree
> > structured". From the comments it seems like a few other people are
> > experimenting with similar approaches. So is it still going to be safe
> > in the long run to assume every webapp has a distinct TCCL, and that it
> > is possible to walk up the classloader ancestry links to find all
> > possible implementations of a particular class?
> 
> I was pointing out that TCCL was being used to track the logging
> environment. For classloading itself, it's up to you to figure it out
> :)

+1

it should be much more reliable to allow per TCCL configuration whilst
loading implementations from the class classloader. IMHO we've encourage
too much use of automagic configuration. suggesting that users use
various arrangements of jars to achieve configurations has proved a poor
plan. limited automagic configuration to just the class classloader
would be a major simplification. 

i've also been toying with the idea of a Log implementation that
discovers which implementation to use based on the calling TCCL. when
debug is called, the Log implementation would be looked up. this would
allow a library to share a static implementation. of course the
configuration for each TCCL would have to be stored centrally.

- robert 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message