Hi, I agree with Piotr, except 3 there is no real point in any change IMHO so think it is 3 for maintenance only or noop without any downside.
Le dim. 11 févr. 2024 à 00:35, Piotr P. Karwasz <piotr.karw...@gmail.com> a écrit : > 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 > >
