[
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: [email protected]
For additional commands, e-mail: [email protected]
