[logging] Odd behaviour with 1.1-RC8

[Simon Kitching <sk...@apache.org>]

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 commons-logging.properties 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 :-)

I'm guessing that although the commons-logging.properties 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.

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.

Regards,

Simon


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

Re: [logging] Odd behaviour with 1.1-RC8

[robert burrell donkin <ro...@blueyonder.co.uk>]

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 commons-logging.properties 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
message.

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

> I'm guessing that although the commons-logging.properties 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
commons-logging.properties 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,
though. 

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