Hi Gary, On Sat, 10 Feb 2024 at 17:26, Gary Gregory <garydgreg...@gmail.com> wrote: > My main driver for the next version is to drop support and dependency > on the Log4j 1.x JARs file(s). I speak of JAR files here as opposed to > APIs, see below.
Log4JLogger is disabled by default in version 1.3.0 (cf. [1]) and the dependency on `log4j:log4j` is optional, so it is a compile-only dependency. If any security expert complains that there is a mention of `log4j:log4j:1.2.17` in the POM file, I would suggest changing security expert. ;-) > I see several ways to drop Log4j 1.x JARs. > 1) Replace the dependency on Log4j 1.x with the Log4j 2 compatibility > JAR for 1.2: org.apache.logging.log4j:log4j-1.2-api > This maintains BC and can become 1.4.0. It shouldn't really matter what JAR we use to compile Commons Logging. People will still use `log4j/reload4j` at runtime. > 2) A re-implementation of Log4JLogger where all methods call Log4j 2 APIs. > This maintains BC and can become 1.4.0. > It looks like this is not possible in a straightforward manner > because we have Log4j 1 classes in the public API, specifically > org.apache.commons.logging.impl.Log4JLogger.Log4JLogger(Logger). It > might not be worth hacking around that if that's even possible. The dependency on `log4j-api` is also optional, so this will break user projects. If users are willing to upgrade to a more modern logging backend than Log4j 1.x, they can do it right now. Release 1.3.0 binds to Log4j API as first choice (followed by SLF4J and JUL), so we already short circuited many logging configurations that were using: 1. commons-logging -> log4j-over-slf4j -> slf4j-api, 2. commons-logging -> log4j-1.2-api -> log4j-api. > 3) A hard delete of org.apache.commons.logging.impl.Log4JLogger (the > class is deprecated in 1.3.0 FWIW). > This breaks BC and requires a 2.0.0 with a package name and Maven > coordinate change. > The package would change from org.apache.commons.logging to > org.apache.commons.logging2. > The Maven coordinates would change from > commons-logging:commons-logging to org.apache.commons:commons-logging2 +1 on removing the class. This seems the only solution, where we make a stand against using 20 years old logging frameworks. Users will still be able to use Log4j 1.x/Reload4J through the `slf4j-reload4j` bridge that Ceki still maintains. I wouldn't change the Maven coordinates/Java package though: Apache Commons Logging is a very primitive interface compared to the alternatives. I doubt anybody will recompile against the new package and legacy libraries will still be stuck at 1.3.0. If a user has to make changes in his code, he might as well migrate to Log4j API (which is a superset of JCL) or SLF4J (which does not allow to log objects, but is mostly "source compatible"). There are automatic recipes for both migrations[2]. > 4) A gutting of Log4JLogger where all methods are no-ops. > This maintains BC and can become 1.4.0. I wouldn't do that. Technically this is not a breaking change, but in practice it breaks user applications. Piotr [1] https://github.com/apache/commons-logging/blob/809f22417beeda262a631362d160ffbbfa34309d/src/main/java/org/apache/commons/logging/impl/LogFactoryImpl.java#L142-L153 [2] https://docs.openrewrite.org/recipes/java/logging --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
