hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: Any plan to upgrade log4j to 2.x
Date Tue, 17 Nov 2015 16:49:45 GMT
See https://issues.apache.org/jira/browse/HBASE-10092 and
https://issues.apache.org/jira/browse/HBASE-11284

One major stumbling block was and is the backwards incompatibility of
configuration file format changes (
https://logging.apache.org/log4j/2.x/manual/migration.html). Someone who
has a HBase installation with v1 properties style logging configuration
will have to replace it with a new XML style configuration where in some
cases there's no mapping from something expressed in v1 to what you can
express in v2 (in my experience).

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 Tue, Nov 17, 2015 at 8:40 AM, Nick Dimiduk <ndimiduk@gmail.com> wrote:

> That is something we discussed a while back. There was probably a JIRA for
> it too. I think simply no one was willing to take on the massive
> search/replace required. IIRC, Mr Purtell experimented with this and found
> migration of configuration files to not work as expected.
>
> It would be good to bite the bullet on this for 2.0. We should decide what
> API we want to assume for the migration -- consume Log4J directly, or go
> through an abstracted API like SLF4J. That's something I planned to look at
> after I finish my patch for bumping our version of
> Yammer/Codahale/Dropwizard metrics. But please, feel free!
>
> On Tuesday, November 17, 2015, Heng Chen <heng.chen.1986@gmail.com> wrote:
>
> > Some projects begin to use log4j 2.x in my company.
> > The API for Log4j 2 is not compatible with Log4j 1.x,
> > So sometimes hbase client log has some conflicts with our project.
> >
>



-- 
Best regards,

   - Andy

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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message