[
https://issues.apache.org/jira/browse/HADOOP-12956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16224915#comment-16224915
]
Sean Busbey commented on HADOOP-12956:
--------------------------------------
{quote}
The only thing that supports the log4j 1 properties files is Log4j 1.x. That
was declared EOL 2 years ago. The last release of Log4j 1 was 5 1/2 years ago.
It doesn't run in Java 9 without hacking it.
{quote}
We're aware of the limitations of log4j 1. The burden on our operators for
changing something as fundamental as logging is still something the project
cares about. I'd be surprised if Hadoop took a hard look at Java 9 before late
2018.
{quote}
At some point you are going to have to get off of Log4j 1.
The log4j team started an effort to create a properties file converter but it
would only be able to convert Appenders & Layouts that are part of Log4j 1
itself. That is working to some degree but is still considered experimental.
Any user created Appenders and Layouts would not be able to be migrated. As we
would not be able to convert them to a Log4j 2 plugin.
That said, we welcome any ideas or contributions anyone wants to contribute to
make the migration easier.
{quote}
I get that it's frustrating to have folks not migrating. I'm a maintainer on a
project that went through a major version change that didn't work well for
operators (HBase in our 0.94 to 0.96 Event Horizon). The task was miserable for
downstream folks as well as those on the project. That was just over 4 years
ago and there are still folks running HBase 0.94.
Frankly, it'd be very helpful for the Log4j community to state plainly and
directly wether or not support for log4j 1 properties files will ever happen.
We (the hadoop project as well as some other communities I watch) have gotten a
mishmash of responses about it being in progress vs not feasible. A hard stance
of "not happening" makes it easier for communities to plan their limited
attention.
{quote}
I should also point out, SLF4J isn't really an answer for this problem either
as Logback doesn't support Log4j 1 configurations and its migration tool can't
handle custom Appenders or Layouts either.
{quote}
SLF4j is exactly the operational answer Hadoop needs. It lets us move our
code's assumptions off of log4j1 while providing a log4j 1 bridge that will
work with existing log4j 1 properties files. That way we can work incrementally
on updating the code base while not requiring operators to change anything.
Once we're done, operators who want to switch early can do so. As a project we
can wait for our next major version to move the default to some other logging
implementation.
> 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-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
