hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-12956) Inevitable Log4j2 migration via slf4j
Date Mon, 30 Oct 2017 14:05:01 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-12956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16224999#comment-16224999
] 

Steve Loughran commented on HADOOP-12956:
-----------------------------------------

Ralph:

* we do want to move to Log4J 2.
* As sean said, we've been wiating for as much aid in migration is possible...this JIRA is
as good a place as any.
* Why do we like to log4j.properties files? Ubiquity, and we understand them. All the Hadoop
cluster management tools are adept at configuring them and pushing them out, which means that
a migration has implications there too.
* In test code we fiddle with logging settings, I don't know where this is done in production.
It is done elsewhere (SPARK-14703).

w.r.t SLF4J

# We've been slowly moving off commons logging to SLF4J for some years, long before worrying
about the Log4J upgrades. Its API is an improvement of commons; even that move is unfinished
but I look forward to the day we get to remove a dependency from everyone's classpath.
# We're still backporting a lot of code from 3.x to branch-2 and commercially supported variants
thereof. Having a single unified log API which works everywhere makes cherry-picking much,
much easier. We have enough pain backporting to want to add more.
# I like to give applications which use hadoop-the-libraries the choice of which back end
to use. Commons logging delivered that, be it log4J or Apache Avalon, even as it added other
bits of complexity (as indeed, SLF4J does).

Do not read this as being any way critical of Log4j: we do intend to move to it as the back
end, we do need to make progress on this. It's hard because of (a) the ubiquity of log statements,
the ubiquity of log4j.property files, and the fact that log4j is a critical part of our infrastructure.
If you haven't spend an afternoon with a 13MB log file from a single service in your IDE trying
to work out WTF is wrong before eventually concluding that the problem was actually occurring
in a different service and only surfacing locally, well, your weekends are different from
ours. for those of us who do get to do that: we care about having the systems configure their
logs such that we do at least get those 13 MB log files.

> 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
>            Assignee: Haohui Mai
>
> {{5 August 2015 --The Apache Logging Services™ Project Management Committee (PMC) has
announced that the Log4j™ 1.x logging framework 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 improved performance
brought about by log4j2.
> https://logging.apache.org/log4j/2.x/manual/async.html#Performance



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-issues-help@hadoop.apache.org


Mime
View raw message