[jboss-jira] [JBoss JIRA] Commented: (JBLOGGING-65) JBoss Logging fails to support log4j-over-slf4j

[Jeff Ramsdale (JIRA)]

    [ https://issues.jboss.org/browse/JBLOGGING-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12609796#comment-12609796 ] 

Jeff Ramsdale commented on JBLOGGING-65:
----------------------------------------

We need to differentiate between applications that use slf4j and utility libraries that use slf4j. slf4j best practices indicate utility libraries should log to the slf4j API (slf4j-api jar) and know nothing of the eventual logging engine. StaticLoggerBinder will not be in their compile-time classpath nor in their declared dependencies. It is up to the consuming application to contribute a StaticLoggerBinder implementation (only one--the discovery of more than one throws a warning and causes slf4j to use a no-op logger).

A common use case in the slf4j world is to have log4j, commons-logging, and java.util.logging all in the classpath (via slf4j adapters, not their native implementations). This ensures all logging is unified via slf4j and only at runtime is a single logging engine selected via the StaticLoggerBinder classloading mechanism. Recursion is only a problem if both an adapter and its corresponding logging engine are both in the classpath at the same time. If this situation occurs slf4j provides a warning. See: http://www.slf4j.org/legacy.html for more details.

> JBoss Logging fails to support log4j-over-slf4j
> -----------------------------------------------
>
>                 Key: JBLOGGING-65
>                 URL: https://issues.jboss.org/browse/JBLOGGING-65
>             Project: JBoss Logging
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.0.0.Beta5-jboss-logging
>            Reporter: Jeff Ramsdale
>            Assignee: David Lloyd
>            Priority: Critical
>
> org.jboss.logging.LoggerProviders tests for the existence of org.apache.log4j.LogManager and if it discovers it assumes Log4j is in use. This is incorrect in the scenario where log4j events are routed to slf4j for eventual routing to another logging engine (a very common use case). This engine may be Logback, but may not. Therefore, the test for whether slf4j is in use is not whether Logback is in the classpath (Logback is AN implementation of slf4j, not THE implementation...), but whether org.slf4j.impl.StaticLoggerBinder is. There should be no attempt to detect Logback itself. JBoss Logging cannot tell through simply loading org.apache.log4j.LogManager whether this class is provided by log4j or by log4j-over-slf4j so cannot use this class to detect log4j use. To clarify, the logic should be:
> 1) If org.slf4j.impl.StaticLoggerBinder is available, use slf4j.
> 2) If org.apache.log4j.LogManager (but not StaticLoggerBinder) is available, use log4j.
> 3) Otherwise use java.util.logging

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira