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 19:32:19 GMT
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.


> 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
id=38499 would be useful.

- robert

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

View raw message