[
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
