[ https://issues.jboss.org/browse/JBLOGGING-65?page=com.atlassian.jira.plug... ] 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. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ 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

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

[ https://issues.jboss.org/browse/JBLOGGING-65?page=com.atlassian.jira.plug... ] David Lloyd commented on JBLOGGING-65: -------------------------------------- JBoss Logging cares if Logback is present because it only logs to one of the four possible backends. If slf4j is present, but you're logging to log4j, jboss-logging should log to log4j. If slf4j is present but you're logging to java.util.logging, then jboss-logging should log to java.util.logging. There is no situation in which forwarding from jboss-logging to slf4j is the right thing to do, unless Logback is present. JBoss Logging's discovery process is not like slf4j which doesn't "discover", it just links against whatever implementation happens to be there. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBLOGGING-65?page=com.atlassian.jira.plug... ] Jeff Ramsdale commented on JBLOGGING-65: ---------------------------------------- Was there a change to correct the log4j detection? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBLOGGING-65?page=com.atlassian.jira.plug... ] Jeff Ramsdale commented on JBLOGGING-65: ---------------------------------------- Great--thanks! And I appreciate your taking the time for the dialog. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira