[ https://issues.jboss.org/browse/JBLOGGING-62?page=com.atlassian.jira.plug... ] Hendy Irawan updated JBLOGGING-62: ---------------------------------- Description: I do see merits in JBoss Logging when compared to SLF4J. However I would love the JBoss Logging team to contribute directly and influence the direction of SLF4J (the API, not implementation) than to create a competing API (of which there are overlap, and JBoss Logging adds some powerful features to the API, like typed loggers, logger injection, typed message bundles/internationalization and more). JBoss Logging can still retain its own logging implementation, much like the way Logback is the implementation of SLF4J API. My suggestion is that the JBoss should submit API improvements to SLF4J, so that on the API level it everybody can use the same rich API that JBoss Logging provided in SLF4J. This would benefit both JBoss and SLF4J communities. was: I do see merits in JBoss Logging when compared to SLF4J. However I would love the JBoss Logging team to contribute directly and influence the direction of SLF4J (the API, not implementation) than to create a competing API (of which there are overlap, and JBoss Logging adds some powerful features to the API, like internationalization and more). JBoss Logging can still retain its own logging implementation, much like the way Logback is the implementation of SLF4J API. My suggestion is that the JBoss should submit API improvements to SLF4J, so that on the API level it everybody can use the same rich API that JBoss Logging provided in SLF4J. This would benefit both JBoss and SLF4J communities. -- 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-62?page=com.atlassian.jira.plug... ] David Lloyd closed JBLOGGING-62. -------------------------------- Resolution: Rejected Just to be perfectly clear, the JBoss Logging API long predates the SLF4J API. In any case, we have strict i18n requirements that are non-negotiable; this makes it hard, if not impossible, for us to rely on an external project, unfortunately. I think you will find that in all of our platforms, we do provide an SLF4J implementation for user deployments (as well as a log4j, commons-logging, and JUL implementation), so we never force the user to use a framework they do not want to use. But for our internal software, we have to use something controlled by us. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira