[
https://issues.apache.org/jira/browse/HADOOP-9864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13990397#comment-13990397
]
Steve Loughran commented on HADOOP-9864:
----------------------------------------
SLF4J is already on the classpath; it backs to log4j. Where we can't use it is
those tests that try to extract the log4j appender from the commons log and
tune its settings, and one of the metrics classes. These can stay with
commons-log.
> 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
> Reporter: Steve Loughran
>
> 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.2#6252)
