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

[Ceki Gülcü]

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.

Now, if log4j had embedded slf4j support, then there would be
no need for nlog4j to exist. It would be dropped on the spot.

Without loss of generality, for the remainder of this discussion I am
going to suppose that log4j does NOT have SLF4J support. (If log4j had
native SLF4J support, nlog4j would not exist and log4j would be
identical to nlog4j (in other words nlog4j would be an alias for
log4j.)

On nlog4j.jar slf4j-jdk14.jar combination:

If your code contains a mix of calls to the log4j API *and* to the
java.util.logging API, then you'd install nlog4j.jar on the
"classpath". The log calls would be handled by the intended
implementation (as expected).

If your code contains a mix of calls to the log4j API *and* to the
slf4j API, then you'd install nlog4j.jar on the "classpath". The log
calls would be handled by the intended implementation (as expected).

If your code contains a mix of calls to the java.util.logging API
*and* to the slf4j API, then you'd install slf4j-jdk14.jar on the
"classpath". The log calls would be handled by the intended
implementation (as expected).

If your code is a mix of calls to the java.util.logging API *and*
slf4j API *and* log4j, then you'd install nlog4j.jar on the
"classpath". The calls to java.util.logging would be handled by
java.util.logging, the calls to log4j would be handled by nlog4j. The
calls to the SLF4J API would also be handled by nlog4j which might be a
problem if the intention was to use java.util.logging for the SLF4J
calls.

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.


-- 
Ceki Gülcü

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