Related, should we move to slf4j for hbase2? This comes of the issue opened by Beluga:"HBASE-19449 Implement SLF4J and SLF4J Parameter Substitution"
In the issue, Duo reminded us of the recent hadoop move to slf4j.The issue is HADOOP-12956. It begins: "5 August 2015 --The Apache Logging Services™ Project Management Committee (PMC) has announced that the Log4j™ 1.x logging framework has reached its end of life (EOL) and is no longer officially supported. https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces A whole framework log4j2 upgrade has to be synchronized, partly for improved performance brought about by log4j2. https://logging.apache.org/log4j/2.x/manual/async.html#Performance"; Other gems in the issue include: "The only thing that supports the log4j 1 properties files is Log4j 1.x. That was declared EOL 2 years ago. The last release of Log4j 1 was 5 1/2 years ago. It doesn't run in Java 9 without hacking it." There is back and forth. log4j2 is a breaking change. It does not support old-style log4j1 properties files. Slf4j does a better job here. Our Sean notes: "SLF4j is exactly the operational answer Hadoop needs. It lets us move our code's assumptions off of log4j1 while providing a log4j 1 bridge that will work with existing log4j 1 properties files. That way we can work incrementally on updating the code base while not requiring operators to change anything. Once we're done, operators who want to switch early can do so. As a project we can wait for our next major version to move the default to some other logging implementation." The LOG4J2-63 issue for supporting log4j1 properties files has not made progress. Hadoop 3 moved to slf4j (and 2.9?). Should we? (Then Beluga can go to work on his convertions... smile). St.Ack On Fri, Dec 8, 2017 at 2:38 PM, dam6923 . <dam6...@gmail.com> wrote: > Hello Team, > > Maybe it's time to finally realize the dream of HBASE-10092 > > Once the logging infrastructure is upgraded, I would be happy to > assist in reviewing and improving the log messages. I've done a bit > of similar work for the Hive project. It's tedious but doesn't > require deep knowledge of the overall project and can be done > piecemeal. > > Commons Logging states that it requires one to use code guards for > logging debug/trace statements. However, SLF4J recommends using > parameters for logging which is faster than guards, and I personally > think it's a cleaner approach. The logging parameters are only > resolved if the log level is appropriate and therefore guards are > often unnecessary. It removes code (the guards) and complexity from > the application code. > > This seems like a straight-forward path for the project for eking out > some performance. > > https://www.slf4j.org/faq.html#logging_performance > https://commons.apache.org/proper/commons-logging/guide.html#Code_Guards > > Thanks. >
