[ https://issues.apache.org/jira/browse/HADOOP-9864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andras Bokor resolved HADOOP-9864. ---------------------------------- Resolution: Duplicate Adopting SLF4J is in progress (or maybe ready?) and it seems the adopting process is not tracked here. This one can be closed. > Adopt SLF4Js over commons-logging > --------------------------------- > > Key: HADOOP-9864 > URL: https://issues.apache.org/jira/browse/HADOOP-9864 > Project: Hadoop Common > Issue Type: Improvement > Affects Versions: 3.0.0-alpha1 > Reporter: Steve Loughran > Priority: Major > > This is fairly major, but it's something to raise. Commons-logging is used as > frozen front end to log4j with a pre-java5-varargs syntax, forcing us to wrap > every log event with an {{if (log.isDebugEnabled()}} clause. > SLF4J > # is the new de-facto standard Java logging API > # does use varags for on-demand stringification {{log.info("routing to {} > , host)}} > # bridges to Log4J > # hooks up direct to logback, which has a reputation for speed through less > lock contention > # still supports the same {{isDebugEnabled()}} probes, so commons-logging > based classes could switch to SLF4J merely by changing the type of the > {{LOG}} class. > Hadoop already depends on SLF4J for jetty support, hadoop-auth uses it > directly. > This JIRA merely proposes making a decision on whether to adopt SL4J -and if > so, how to roll it out. > The least-disruptive roll-out strategy would be to mandate it on new modules, > then switch module-by-module in the existing code. > We'd also need to find all those tests that dig down to log4j directly, and > make sure that they can migrate to the new APIs. -- This message was sent by Atlassian JIRA (v6.4.14#64029) --------------------------------------------------------------------- To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org