Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-issues@hadoop.apache.org
Date: Tue, 29 Mar 2016 17:28:25 +0000 (UTC)
From: "Chris Nauroth (JIRA)" <jira@apache.org>
To: common-issues@hadoop.apache.org
Message-ID: <JIRA.12952690.1458709758000.78384.1459272505687@Atlassian.JIRA>
In-Reply-To: <JIRA.12952690.1458709758000@Atlassian.JIRA>
References: <JIRA.12952690.1458709758000@Atlassian.JIRA>
 <JIRA.12952690.1458709758083@arcas>
Subject: [jira] [Commented] (HADOOP-12956) Inevitable Log4j2 migration via
 slf4j
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/HADOOP-12956?page=3Dcom.atlassi=
an.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D15=
216395#comment-15216395 ]=20

Chris Nauroth commented on HADOOP-12956:
----------------------------------------

bq. Has anyone spoken to the Log4J team about this?

>From what I can tell, the Log4J 2 domain model has changed so significantly=
 that they don't consider it workable to attempt full backwards-compatibili=
ty with Log4J 1 style configuration.  We could certainly ask again though.

I did have a brief conversation about losing our ability to switch logging =
levels by passing -D arguments.  They had a suggestion for plugging in to t=
he Log4J 2 internals to accomplish this, but I haven't had time to try it.

http://mail-archives.apache.org/mod_mbox/logging-log4j-user/201602.mbox/%3C=
D35E0663-D78B-4DAF-A26A-F5A27E8A14FC%40dslextreme.com%3E

I don't have any concrete information about the mixing problem at this poin=
t.  I expect it will require experimentation to figure out what is possible=
.

bq. Would the log tuning servlets work? They are invaluable for debugging l=
ive services.

This is implemented with Commons Logging calls to change the levels.  I did=
n't investigate anything related to Commons Logging, because ZooKeeper has =
already fully migrated to SLF4J as the logging API.  Even if this doesn't w=
ork, I'd expect it could be made to work by switching the code to call equi=
valent Log4J 2 APIs.

bq. we can still continue the move to SLF4J APIs, even for branch-2 code.

+1


> Inevitable Log4j2 migration via slf4j
> -------------------------------------
>
>                 Key: HADOOP-12956
>                 URL: https://issues.apache.org/jira/browse/HADOOP-12956
>             Project: Hadoop Common
>          Issue Type: Improvement
>            Reporter: Gopal V
>
> {{5 August 2015 --The Apache Logging Services=E2=84=A2 Project Management=
 Committee (PMC) has announced that the Log4j=E2=84=A2 1.x logging framewor=
k has reached its end of life (EOL) and is no longer officially supported.}=
}
> https://blogs.apache.org/foundation/entry/apache_logging_services_project=
_announces
> A whole framework log4j2 upgrade has to be synchronized, partly for impro=
ved performance brought about by log4j2.
> https://logging.apache.org/log4j/2.x/manual/async.html#Performance


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)