[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... ] 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. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira