commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject Re: [logging] JCL 1.1 status
Date Wed, 08 Feb 2006 21:15:16 GMT
On Wed, 2006-02-08 at 19:32 +0000, robert burrell donkin wrote:
> On Wed, 2006-02-08 at 19:02 +1300, Simon Kitching wrote:


> > Regarding the "badly behaved TCCL" thing, I remember some discussion
> > earlier on this topic. Someone raised a bugzilla entry requesting
> > something like this, to handle a JCI invocation. In this case, there are
> > two webapps in a container, and one gets a reference to an object in
> > another via a JNDI lookup and then invokes it. The thread with the
> > original app's TCCL is then executing inside the other webapp's classes!
> > I think I turned the proposed change down, though, and for a good reason
> > - which I've now forgotten. I'll need to trawl through the closed
> > bugzilla reports to find the details.
> this is really to address a change in behaviour since 1.0.2. i ran RC2
> on an ant task. this works with 1.0.2 but fails with RC2. this is due to
> JCL not being available to the TCCL when the task executes. we need to
> find a way round this one but please take a look and make sure that i
> haven't missed anything.

i've thought of one situation where the patch may have some negative
impact. the current patch uses the following order:

for each log
  TCCL classloader hierarchy
  LogFactoryImpl class classloader

this may produce different results to:

for each log
  TCCL classloader hierarchy

for each log
  LogFactoryImpl class classloader

however, in the cases where this order actually matters i suspect that
the adapter in the TCCL would use a Log class which is not equal to that
loaded by the LogFactoryImpl class classloader. need some time to
confirm or reject this...

- robert

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message