You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Simon Kitching <sk...@apache.org> on 2006/02/08 07:02:34 UTC

[logging] JCL 1.1 status

Hi All,

I'm back from my trip and ready to help with the logging 1.1 release
again.

Robert, I see from the email archives that you've been working on a
couple of logging issues.

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.

I'm a bit confused by your patch for the "getParent returns null" thing.
I'll have a second look, though, and see if I can get my head around it.

Have you fixed the "guards needed around diagnostic output" issue? If
not, I'm happy to double-check for any problem cases. Note, however,
that diagnostics are never output during normal logging operation, only
during the discovery/initialisation bits. Those really aren't
time-critical as they only occur once per webapp, and at a time when we
are scanning the classpath for config files, etc., which has far more
impact on performance than a few string concatenations.

Cheers,

Simon


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


Re: [logging] JCL 1.1 status

Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
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:

<snip>

> > 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Re: [logging] JCL 1.1 status

Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Wed, 2006-02-08 at 19:02 +1300, Simon Kitching wrote:
> Hi All,
> 
> I'm back from my trip and ready to help with the logging 1.1 release
> again.

trust you enjoyed it :)

> Robert, I see from the email archives that you've been working on a
> couple of logging issues.

yep

> 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'm a bit confused by your patch for the "getParent returns null" thing.
> I'll have a second look, though, and see if I can get my head around it.

i noticed it whilst investigating badly behaved TCCL's. the existing
code was theoretically incorrect but i doubt that it'll make much
practical difference. the code required to cater for this technical
possibility is large and complex but is very unlikely to be execute
under any Sun JVM. might be better to revert this patch and give some
diagnostics instead.

> Have you fixed the "guards needed around diagnostic output" issue? If
> not, I'm happy to double-check for any problem cases. Note, however,
> that diagnostics are never output during normal logging operation, only
> during the discovery/initialisation bits. Those really aren't
> time-critical as they only occur once per webapp, and at a time when we
> are scanning the classpath for config files, etc., which has far more
> impact on performance than a few string concatenations.

just a neatness thing: it's this kind of stuff that users regularly turn
up when they analyse the code. i don't think it'll make very much
difference to real life performance but i have a few improvements i'd
like to make to the outputs in any case so i thought i might as well go
through and tidy up.

another opinion on http://issues.apache.org/bugzilla/show_bug.cgi?
id=38499 would be useful.

- robert


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