[slf4j-dev] org.slf4j.LoggerFactory in [n]log4j.jar

[Curt Arnold]

On May 17, 2005, at 4:18 AM, Ceki Gülcü wrote:

> At 19:55 5/16/2005, Curt Arnold wrote:
>
>> nlog4j.jar and the CVS HEAD of log4j both contain an implementation
>> of org.slf4j.LoggerFactory.  I think that this might not be a good
>> thing since it implies that if any component uses [n]log4j for its
>> internal logging that [n]log4j should contend as a provider for SLF4J
>> logging.
>>
>> For example, say I have a ancillary jar file that uses log4j 1.2.9
>> for its diagnostic logging, but logging is seldom enabled since the
>> component just works.  This ancillary jar is used in an web
>> application that uses SLF4J interfaces and slf4j-jdk14.jar is on the
>> classpath since the application configurator wanted to use JDK 1.4
>> logging for logging from the main application logic.  If the
>> ancillary component is then updated to use nlog4j that contains an
>> implementation of org.slf4j.LoggerFactory, then the SLF4J
>> implementation actually used by the web application would depend on
>> the relative position of nlog4j.jar and slf4j-jdk14.jar in the
>> classpath.
>>
>
> On log4j nlog4j combination:
>
> It's highly unlikely that someone would want to use log4j and nlog4j
> at the same time. Actually it does not make sense to use both
> simultaneously. One would use log4j if they did not care about SLF4J
> and use nlogj for SLF4J support.

I was not suggesting that they be used in combination, but that both  
log4j.jar from the current CVS HEAD and nlog4j.jar (fork from the  
log4j 1.2 branch) result in the same behavior since they both contain  
implementations of org.slf4j.LoggerFactory.

>
> Sub-problem: calls to the SLF4J API are handled by nlog4j instead of
> java.util.logging (the desired API).
>
> Case 1) If the *application* itself (not an imported library but the
> application) intentionally contained calls to log4j, then one can
> presume that application's intention could not possibly have been to
> use java.util.logging (instead of nlog4j) to handle the SLF4J calls.
>
> Case 2) If an imported library decided to use log4j directly instead
> of SLF4J, then this library in effect imposes nlog4j on the SLF4J  
> class
> made by the rest of the application.
>
> Considering the alternatives, I don't think case 2 is a show stopper
> for SLF4J.
>

Case 2 is exactly what I was trying to describe.  It seems like a  
valid concern to me and suggests to me that it would be better to  
have a separate slf4j-log4j.jar than to embed org.slf4j.LoggerFactory  
in log4j.jar.