hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <ste...@hortonworks.com>
Subject Re: Log4J 1.x -> EoL
Date Tue, 01 Sep 2015 12:41:35 GMT

> On 31 Aug 2015, at 19:52, Andrew Purtell <apurtell@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.



Mime
View raw message