The commons logging wiki FAQ page
(http://wiki.apache.org/jakarta-commons/Logging/FrequentlyAskedQuestions) has
this:
<extract>
== Log4JLogger does not implement Log ==
{{{
I have an exception with message 'Log4JLogger does not implement Log'!
What's the cause and how can I fix this problem?
}}}
This almost always a classloader issue. Log has been loaded by a
different classloader from Log4JLogger. Please ensure that:
* all the logging classes (both Log and the logging implementations) are
deployed by the same classloader
* there is only copy of the classes to be found within the classloader
hierarchy. In application container environments this means ensuring
that if the classes are found in a parent classloader, they are not also
present in the leaf classloader associated with the application. So, if
the jar is deployed within the root classloader of the container then it
should be removed from the application's library.
</extract>
I think the last bullet point is too strict; having multiple copies of
commons-logging.jar should be fine, as long as child-first classloading
is being used (which it should be). I believe that following this
recommendation would actually break tomcat 5.x; I believe it *needs*
commons-logging-api.jar in $CATALINA_HOME/common/lib to operate
correctly. See:
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/class-loader-howto.html
Here's my suggested replacement text:
<text>
Ensure that both the Log and the Log4JLogger classes used by your
component (webapp/EJB/other) have been deployed from the same
classloader. In particular, ensure that commons-logging-api.jar (which
only provides Log) is not in the path of a classloader which is searched
"before" a classloader that provides commons-logging.jar (which provides
both classes).
When using a framework that uses standard "child-first" class loading
order for a component, simply deploying commons-logging.jar in the
component's private library path (eg WEB-INF/lib) should be sufficient.
When using a framework that does "parent-first" classloading, it may be
necessary to replace any copies of commons-logging-api.jar in the
"shared" libs directory with the full commons-logging.jar (or remove the
commons-logging-api.jar, though that might have undesirable side-effects
if it is required by other components or the framework).
</text>
Cheers,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
