On Mon, 2006-02-20 at 13:31 +0100, Remy Maucherat wrote: > On 2/20/06, Simon Kitching <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
