hadoop-common-issues mailing list archives

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

    [ 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:

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.

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.

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

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.

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

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

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

View raw message