Re: Any plan to upgrade log4j to 2.x
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 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 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 > 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
Re: Any plan to upgrade log4j to 2.x
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 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 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)
Re: Any plan to upgrade log4j to 2.x
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 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. >
Any plan to upgrade log4j to 2.x
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.
