[
https://issues.apache.org/jira/browse/HADOOP-16377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16867095#comment-16867095
]
Steve Loughran commented on HADOOP-16377:
-----------------------------------------
org.slfj imports shouldn't be added to the same block as the org.apache ones.
The order is nominally
java.*
--
non-org.apache
--
org.apache.*
--
static
I know we don't maintain this well, and once things are in we don't move them
about for fear of creating merge problems -but lets try to do our best on new
imports.
Other than that, looks ok.
In {{FileSystem}}, we created a private Logger instance , {{LOGGER}} to move to
SLF4J while leaving the public one alone (HADOOP-13605). If the public LOG goes
to SLF4J then we could combine them -move the LOGGER refs over to LOG.
We could just delete the LOG entry and force all bits of code referring to it
to move to their own private log. As I recall, the reasons to not do this were
* we didn't know what external apps were using it (i.e. was it used by
subclasses)
* we were worried about whether people expected our internal uses to be
controlled by the o.a.fs.FileSystem log settings
Given this breaks compatibility with any external uses. how about we remove and
force our own code to have private logs
> Moving logging APIs over to slf4j
> ---------------------------------
>
> Key: HADOOP-16377
> URL: https://issues.apache.org/jira/browse/HADOOP-16377
> Project: Hadoop Common
> Issue Type: Improvement
> Reporter: Wei-Chiu Chuang
> Assignee: Prabhu Joseph
> Priority: Major
> Attachments: HADOOP-16377-001.patch
>
>
> As of today, there are still 50 references to log4j1
> {code}
> $ grep -r "import org.apache.commons.logging.Log;" . |wc - l
> 50
> {code}
> To achieve the goal of HADOOP-12956/HADOOP-16206, we should invest time to
> move them to slf4j
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]