You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-issues@hadoop.apache.org by "Steve Loughran (JIRA)" <ji...@apache.org> on 2014/05/06 09:54:17 UTC

[jira] [Commented] (HADOOP-9864) Adopt SLF4Js over commons-logging

    [ 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)