[
https://issues.apache.org/jira/browse/OOZIE-3136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16641844#comment-16641844
]
Julia Kinga Marton edited comment on OOZIE-3136 at 10/8/18 2:40 PM:
--------------------------------------------------------------------
The upgrade can be done in two ways:
# Use the log4j1.x bridge: this is quite trivial solution: we need to replace
the log4j dependency with log4j-1.2-api. However if there are places when we
touched/used legacy Log4j1 classes such as Appenders, LoggerRepository or
Category it may need a small refactoring. Using this bridge, all logging that
uses Log4j 1 will be routed to Log4j 2.
# Convert manually to the Log4j2 api and update the configuration. This is a
more complex solution. On the one hand, there are some calls what are changed
in Log4j2, on the other hand, however Log4j2 supports configuration via a
.properties file, the syntax is changed, so we need to reconfigure our
framework.
Having this configuration syntax changed, proceeding with manual conversion
will break compatibility. There is an issue when the Log4j guys will address
this incompatibility, but this is still in progress: LOG4J2-63. I don't think
that we should wait for this issue.
However I consider the second solution a more elegant solution, I think that we
should keep somehow backwards compatibility, and proceed with the bridge.
[~andras.piros], [~asalamon74], and others, what is your opinion?
You can find more information related the migration here:
[https://logging.apache.org/log4j/2.x/manual/migration.html]
was (Author: kmarton):
The upgrade can be done in two ways:
# Use the log4j1.x bridge: this is quite trivial solution: we need to replace
the log4j dependency with log4j-1.2-api. However if there are places when we
touched/used legacy Log4j1 classes such as Appenders, LoggerRepository or
Category it may need a small refactoring. Using this bridge, all logging that
uses Log4j 1 will be routed to Log4j 2.
# Convert manually to the Log4j2 api and update the configuration. This is a
more complex solution. On the one hand, there are some calls what are changed
in Log4j2, on the other hand, however Log4j2 supports configuration via a
.properties file, the syntax is changed, so we need to reconfigure our
framework.
Having this configuration syntax changed, proceeding with manual conversion
will brake compatibility. There is an issue when the Log4j guys will address
this incompatibility, but this is still in progress: LOG4J2-63. I don't think
that we should wait for this issue.
However I consider the second solution a more elegant solution, I think that we
should keep somehow backwards compatibility, and proceed with the bridge.
[~andras.piros], [~asalamon74], and others, what is your opinion?
You can find more information related the migration here:
[https://logging.apache.org/log4j/2.x/manual/migration.html]
> Upgrade from Log4j 1.x to 2.x
> -----------------------------
>
> Key: OOZIE-3136
> URL: https://issues.apache.org/jira/browse/OOZIE-3136
> Project: Oozie
> Issue Type: Sub-task
> Reporter: Attila Sasvari
> Assignee: Julia Kinga Marton
> Priority: Major
>
> {{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
> We should upgrade from Log4j 1.x to 2.x . Perhaps we could use slf4j .
> Related tickets: MAPREDUCE-6983, HADOOP-12956, OOZIE-3135
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
