I've been made wary of log4j2 recently due to introducing breaking changes to log output in patch releases[1].
[1]: e.g. https://issues.apache.org/jira/browse/LOG4J2-670 which was referenced in described notes just as "DatePatternConverter ISO8601_PATTERN now conforms to ISO8601." On Tue, Nov 17, 2015 at 10:49 AM, Andrew Purtell <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> > 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) > -- Sean
