> 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 <[email protected]> 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)
