You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-dev@hadoop.apache.org by Steve Loughran <st...@hortonworks.com> on 2015/08/31 14:43:35 UTC

Log4J 1.x -> EoL

https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces

As of early August, Log4J 1.x is now officially dead



outside some of the test runners, nothing in the code itself assumes log4j, just commons logging. Presumably the tests could be patched to move to 2.x -though as they do some classcasts from commons-logging instances to get the log4j back end and turn down the output, it may be tricky.

Otherwise:
1. Who knows what changes in the log4j configs? Will they still all work
2. Things are going to change downstream if hadoop pulls log4j 1.x. Managing the transition is going to be fun.



Re: Log4J 1.x -> EoL

Posted by Steve Loughran <st...@hortonworks.com>.
> On 31 Aug 2015, at 19:52, Andrew Purtell <ap...@apache.org> wrote:
> 
>> Who knows what changes in the log4j configs? Will they still all work
> 
> We looked at moving up to log4j2 over in HBase. One major stumbling block
> was the backwards incompatibility of configuration file format changes (
> https://logging.apache.org/log4j/2.x/manual/migration.html). There is a
> bridge (https://logging.apache.org/log4j/log4j-2.2/log4j-1.2-api/index.html)
> but this enables unmodified _code_ to run on v2 implementation and
> configuration, it doesn't support configuring v2 code with v1 configuration
> files. Hadoop and downstream projects uses log4j1's Java properties style
> configuration format. This option isn't available for log4j2 (
> http://stackoverflow.com/questions/22485074/log4j-2-doesnt-support-log4j-properties-file-anymore).
> I vaguely remember some Hadoop-ish log configuration options in the v1
> properties files were not possible to express in the v2 format. Fortunately
> it does seem possible to implement your own custom configuration processor
> for v1 configuration files (
> https://logging.apache.org/log4j/log4j-2.2/manual/extending.html)
> 


That pretty much kills off the migration as a short term action, then doesn't it?

Those log4j.properties files are ubiquitous, the management tooling creating them, and things like rolling logs/log aggregation depending
upon the naming schemes.



Re: Log4J 1.x -> EoL

Posted by Andrew Purtell <ap...@apache.org>.
> Who knows what changes in the log4j configs? Will they still all work

We looked at moving up to log4j2 over in HBase. One major stumbling block
was the backwards incompatibility of configuration file format changes (
https://logging.apache.org/log4j/2.x/manual/migration.html). There is a
bridge (https://logging.apache.org/log4j/log4j-2.2/log4j-1.2-api/index.html)
but this enables unmodified _code_ to run on v2 implementation and
configuration, it doesn't support configuring v2 code with v1 configuration
files. Hadoop and downstream projects uses log4j1's Java properties style
configuration format. This option isn't available for log4j2 (
http://stackoverflow.com/questions/22485074/log4j-2-doesnt-support-log4j-properties-file-anymore).
I vaguely remember some Hadoop-ish log configuration options in the v1
properties files were not possible to express in the v2 format. Fortunately
it does seem possible to implement your own custom configuration processor
for v1 configuration files (
https://logging.apache.org/log4j/log4j-2.2/manual/extending.html)


On Mon, Aug 31, 2015 at 5:43 AM, Steve Loughran <st...@hortonworks.com>
wrote:

>
>
> https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces
>
> As of early August, Log4J 1.x is now officially dead
>
>
>
> outside some of the test runners, nothing in the code itself assumes
> log4j, just commons logging. Presumably the tests could be patched to move
> to 2.x -though as they do some classcasts from commons-logging instances to
> get the log4j back end and turn down the output, it may be tricky.
>
> Otherwise:
> 1. Who knows what changes in the log4j configs? Will they still all work
> 2. Things are going to change downstream if hadoop pulls log4j 1.x.
> Managing the transition is going to be fun.
>
>
>


-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)