commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <skitch...@apache.org>
Subject Re: Log4JLogger does not implement Log
Date Fri, 20 May 2005 22:36:26 GMT
On Fri, 2005-05-20 at 10:49 -0700, Michael Oliver wrote:
> When I run this target I get
> 
>  
> 
> [axis-java2wsdl] Caused by:
> org.apache.commons.logging.LogConfigurationException:
> org.apache.commons.logging.LogConfigurationException:
> org.apache.commons.logging.LogConfigurationException: Class
> org.apache.commons.logging.impl.Log4JLogger does not implement Log
> 
> [axis-java2wsdl] at
> org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImp
> l.java:532)...
> 
>  
> 
> So researching this I find that the "Log4JLogger does not implement Log"
> is caused by a classloader problem.
> 
>  
> 
> So I found in the eclipse ant runtime preferences Global Entries, both
> the commons-logging and log4j jars.  So I removed them from there and
> ran ant on that target again...
> 
>  
> 
> axis-java2wsdl:
> 
>      [echo] Building wsdl for AlariusAssignments at
> C:\Java\ArchivedWorkspaces\AlariusAssignments\AlariusAssignments.wsdl}
> 
> [axis-java2wsdl] java.lang.NoClassDefFoundError:
> org.apache.commons.logging.LogFactory
> 
> [axis-java2wsdl] at
> org.apache.axis.components.logger.LogFactory.class$(LogFactory.java:84)
> 
> ...
> 
>  
> 
> Huh???
> 
>  
> 
> If the ant runtime is loading the commons-logging and log4j jars and
> that causes a classloader sequence problem, then removing them from
> there and leaving the ones in the compile.classpath should NOT cause a
> NoClassDefFoundError.
> 
>  
> 
> How can it be that one way it doesn't find LogFactory and the other way
> it has a classloader sequence problem?

This problem is caused when you have *all* of the following true:
 * child-first classloading order selected in child classloader
 * code in child classloader that calls JCL
 * commons-logging.jar available via child classloader
 * code in shared classloader that calls JCL
 * commons-logging.jar available via shared classloader

Because you have code in the shared classloader that calls JCL, you
*must* deploy commons-logging.jar at the shared level.

So the simplest fix is to delete the commons-logging.jar from the child
classloader. The downside of this is that all your logging config then
becomes "global", ie you need to configure logging using a config file
at the shared level, and webapps share the same logging instance. But I
don't think you really care about logging in this case do you?


Regards,

Simon


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


Mime
View raw message