commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject Re: [logging] Odd behaviour with 1.1-RC8
Date Thu, 13 Apr 2006 17:03:53 GMT
On Thu, 2006-04-13 at 22:30 +1200, Simon Kitching wrote:
> Hi,
> Unfortunately I have to report what appears to be a problem with
> 1.1-RC8. I haven't quite got to the cause of this issue yet, but as I'm
> unsure whether I'll have time over this Easter break to look into it I
> thought I should briefly describe it here.
> Setup: Tomcat 5.5.15, Java1.5, Windows.
> A webapp has commons-logging-1.0.4 and log4j-1.2.13 in its WEB-INF/lib
> directory. The webapp has a file specifying
> Log4JLogger. Everything works fine.
> Replacing tomcat's bin/commons-logging-api.jar file with
> commons-logging-1.1-RC8 causes the webapp to throw a
> LogConfigurationException on startup. Enabling diagnostics indicates
> that attempting to load class Log4JLogger causes NoClassDefFound on
> org.apache.log4j.Category. This class is *definitely* present in the
> log4j-1.2.13.jar file.
> Amusingly, the error message reported is:
> <quote>
> org.apache.commons.logging.LogConfigurationException: User-specified log
> class 'org.apache.commons.logging.impl.Log4JLogger' cannot be found or
> is not useable. Did you mean
> 'org.apache.commons.logging.impl.Log4JLogger'?
> </quote>
> which isn't terribly helpful :-)

mea culpa

the last sentence in the message is added when the name of the custom
implementation is similar. helps to catch mispeilings. when the name is
identical to one of the usual suspects, should append a different

i'll apply a fix (unless you get their first)

> I'm guessing that although the file is being
> found in the webapp, the Log4JLogger class is being loaded from the
> commons-logging jarfile in tomcat's bin directory (SYSTEM classloader),
> not the webapp classloader, hence log4j classes not being found. I don't
> understand why this would be, but it's the best theory at the moment.

this sounds very plausible

perhaps 1.0.4 doesn't check the child classloader for the file and instead defaults to using
java.util.logging. extra logic was added to 1.1 in this area so perhaps
this configuration is picked up now. not sure why the context
classloader isn't loading the log from the jar in the web application,

> The situation is occurring in a real-life app which is too complicated
> to post here. I'll try to emulate it in a simpler "test case" when I
> have time.
> While reading the diagnostics output, I've noticed that there could be
> some improvement in this area. This isn't important enough to hold back
> release by itself, but if we're doing more work I might tweak this
> output too.

i plan to post something to the list cancelling the vote so please go
ahead. if you could update the troubleshooting document with any traces
that have change that'd be great.

- robert

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

View raw message