I am afraid this one is due to a incompatibility between LOG4J and
NLOG4J/SLF4J, and not to an error in JCL.  While printing methods in
LOG4J take an argument of type java.lang.Object, the org.slf4j.Logger
interface imposes that this parameter be of type
java.lang.String. NLOG4J Logger's which directly implement the
org.slf4j.Logger interface relays this restriction -- hence the
NoSuchMethodError you are observing. JCL merely reveals this
LOG4J/NLOG4J incompatibility.

What can be done? It should be fairly easy to add an NLOG4J adapter to
JCL. I'll start working on this right now and report back here and on
the dev@SLF4J.org mailing list.

Nick, it's not bad configuration on your part. I hope this incident
will not scare you off from using the SLF4J API. Perhaps you should
wait until the incident is resolved before making up your mind.

In any case, thank you for reporting this problem. Caught early, the
problem can be fixed before future users are affected.

At 06:26 AM 7/5/2005, Nick Faiz wrote:
>Hi guys,
>    A note to all of this.
>
>    I sat down on the weekend to make SLF4J run. I immediately encountered 
> a NoSuchMethodError via a Spring dependency, via commons-logging, to 
> log4j (while I was running with nlog4j). I began digging around to find 
> the missing method (a call to a log(msg, priority, obj, throwable) in 
> Category, I believe) but didn't really want to spend my Saturday 
> afternoon working on a transitional problem.
>
>    I'll work on this problem and report it in more detail, later. Or 
> perhaps it was a bad configuration on my part.
>
>    This *does not* feel like the path of least resistance, however, 
> towards getting something as fundamental as logging in place.
>
>Cheers,
>Nick

-- 
Ceki Gülcü

   The complete log4j manual: http://www.qos.ch/log4j/