You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by DE BENEDICTIS DAVIDE <dd...@sogei.it> on 2004/09/01 09:49:13 UTC

RE: Problems logging from a Junit test

 

> -----Original Message-----
> From: David Durham [mailto:david.durham1@scott.af.mil] 
> Sent: Tuesday, August 31, 2004 11:28 PM
> To: Log4J Users List
> Subject: Re: Problems logging from a Junit test
> 
> ... [SNIP]...
> and it now looks for log4j.properties in .../WEB-INF/classes 
> before looking through the various jars (I'm using JDK 
> 1.4.2_03).  Presumably all classloaders will search for 
> resources similarly.
> 
> BTW, the offending Jar (at least the first one I found) was 
> xdoclet-1.2.1.  Why would they put a log4j.properties file in 
> that jar?  
> I guess that's a question for the xdoclet list.

I'm off topic here but...
Last week I was trying to use the latest Jetty 5.0RC2 (that for the
first time it uses commos-logging) inside my JBuilder, I was always
getting:

> org.apache.commons.logging.LogConfigurationException: Class 
> org.apache.commons.logging.impl.Log4JLogger does not
> implement Log 	at 
> org.apache.commons.logging.impl.LogFactoryImpl.newInstance(Log
> FactoryImpl.java:532)

Outside JBuilder everything was fine but within it in some way his
classpath was getting dirty in a misterious way. I was nearly removing
all log4j jars from my disk, then after suggestion from Greg Wilkins on
jetty list I had to force Jetty classloader with:

   context.setClassLoaderJava2Compliant(true);

So, problem solved, but I cannot explain really what was going on.

Bye

--
Davide


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org