[jboss-jira] [JBoss JIRA] Commented: (JBLOGGING-65) JBoss Logging fails to support log4j-over-slf4j
[
https://issues.jboss.org/browse/JBLOGGING-65?page=com.atlassian.jira.plug...
]
David Lloyd commented on JBLOGGING-65:
--------------------------------------
I think you may also be confused in that JBoss Logging does not select a backend at
compile time. It uses a run-time, one-time discovery process to see which of the four
possible logging backends to use based on its visible class path.
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