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 2013/08/12 19:32:51 UTC

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

Steve Loughran created HADOOP-9864:
--------------------------------------

             Summary: 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 log4k 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira