[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=12609809#comment-12609809 ] 

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

Why would JBoss Logging need to know what the backend is that slf4j is using? It's not its concern. Your statement that #1 will be falsely triggered is incorrect because slf4j-api (the compile-time binding clients log against) does not provide a StaticLoggerBinder. StaticLoggerBinder is only available if the user has provided an adapter or a logging implementation that contains the class. In JBoss's case that would be slf4j-jboss-logmanager but in other cases it could be an alternative implementation selected by the user.

I think we need to change our approach. There are two issues we're trying to solve--how to route slf4j-based logging to JBoss Logging and how to route JBoss Logging to slf4j. The first is covered by slf4j-jboss-logmanager, which can be added to an application's classpath and fulfills the expected slf4j contract of providing a StaticLoggerBinder. The Second is broken, and to fulfill the slf4j pattern would require an alternative JBoss Logging jar (say, jboss-logging-over-slfj, to be consistent with slf4j nomenclature) that internally uses slf4j logging mechanisms but fulfills the JBoss Logging API at compile time. In the absence of such a jar utilities that worked prior to the introduction of JBoss Logging (e.g. Infinispan and Hibernate) may fail upon upgrade. An application classpath change would be required with the upgrade, but no code change.

> 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