[LOGGING] 2.0
I'd like to plan and start working on a 2.0 release of commons-logging with the specific goal of resolving the large number of out of date, unsupported, old libraries that this project pulls into so many dependency trees. There's been some discussion of a 2.0 release in JIra at https://issues.apache.org/jira/projects/LOGGING/issues/LOGGING-187 but I'd lik to bring this to a wider audience. Specifically my thoughts are: 1. 2.0 will be technically API incompatible since it will remove all traces of EOL libraries like log4j 1.x and avalon. 2. It will otherwise be a drop-in replacement for anyone not using these old libraries. Specifically: * Other deprecated methods are not removed. * The package name does not change. * The group ID and artifact ID do not change. * Minimum Java version remains 1.8 3. It can include any recent, API compatible bug fixes and new features that are available at HEAD, but these are not blockers. While there are other more incompatible changes that could be made in a major version bump, I think it's really important to produce a drop-in replacement that is friendlier to security scanners and dependency analyzers. I do not want to discourage people from upgrading for any reason other than they're still using EOL libraries like log4j 1.x. 1.3.0 was recently released and seems up to date with the last several years of changes and bugs, so it feels like a good time to make the break. Anyone who isn't ready to give up their decade+ old loggers can stay on this release for a while. However if there's a strong need to maintain a 1.x branch that could be done too. Or we could start 2.x as a separate branch. If this achieves rough consensus, I can start sending PRs. However, the final release would require a commons committer or perhaps PMC member to take over. Thoughts? -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [LOGGING] 2.0
Hi All: I want to focus on content before we decide what label to put on the next release. Then, we can see if we want to break binary compatibility (BC) for a Commons Logging 2.0.0. 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. 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. 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. 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 4) A gutting of Log4JLogger where all methods are no-ops. This maintains BC and can become 1.4.0. I like (1) the best, it gives us a clear path to a 1.4.0 without breaking BC and removes dependencies on the 1.x jars. >From my POV breaking BC in Logging 1.x is a non-starter. Then, if we want to remove support for the Log4j 1 API (the JAR is already gone at this point), that would necessitate a 2.0.0. Gary On Sat, Feb 10, 2024 at 8:53 AM Elliotte Rusty Harold wrote: > > I'd like to plan and start working on a 2.0 release of commons-logging > with the specific goal of resolving the large number of out of date, > unsupported, old libraries that this project pulls into so many > dependency trees. There's been some discussion of a 2.0 release in > JIra at https://issues.apache.org/jira/projects/LOGGING/issues/LOGGING-187 > but I'd lik to bring this to a wider audience. Specifically my > thoughts are: > > 1. 2.0 will be technically API incompatible since it will remove all > traces of EOL libraries like log4j 1.x and avalon. > 2. It will otherwise be a drop-in replacement for anyone not using > these old libraries. Specifically: > * Other deprecated methods are not removed. > * The package name does not change. > * The group ID and artifact ID do not change. > * Minimum Java version remains 1.8 > 3. It can include any recent, API compatible bug fixes and new > features that are available at HEAD, but these are not blockers. > > While there are other more incompatible changes that could be made in > a major version bump, I think it's really important to produce a > drop-in replacement that is friendlier to security scanners and > dependency analyzers. I do not want to discourage people from > upgrading for any reason other than they're still using EOL libraries > like log4j 1.x. > > 1.3.0 was recently released and seems up to date with the last several > years of changes and bugs, so it feels like a good time to make the > break. Anyone who isn't ready to give up their decade+ old loggers can > stay on this release for a while. However if there's a strong need to > maintain a 1.x branch that could be done too. Or we could start 2.x > as a separate branch. > > If this achieves rough consensus, I can start sending PRs. However, > the final release would require a commons committer or perhaps PMC > member to take over. > > Thoughts? > > -- > Elliotte Rusty Harold > elh...@ibiblio.org > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [LOGGING] 2.0
On Sat, 10 Feb 2024 at 16:27, Gary Gregory wrote: > > Hi All: > > I want to focus on content before we decide what label to put on the > next release. Then, we can see if we want to break binary > compatibility (BC) for a Commons Logging 2.0.0. > > 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. > > 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. > 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. Isn't that much the same as re-implementing option 1? > 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 > 4) A gutting of Log4JLogger where all methods are no-ops. Surely it would be better to throw an Exception rather than silently drop what could be important info? > This maintains BC and can become 1.4.0. > I like (1) the best, it gives us a clear path to a 1.4.0 without > breaking BC and removes dependencies on the 1.x jars. > From my POV breaking BC in Logging 1.x is a non-starter. > > Then, if we want to remove support for the Log4j 1 API (the JAR is > already gone at this point), that would necessitate a 2.0.0. > > Gary > > On Sat, Feb 10, 2024 at 8:53 AM Elliotte Rusty Harold > wrote: > > > > I'd like to plan and start working on a 2.0 release of commons-logging > > with the specific goal of resolving the large number of out of date, > > unsupported, old libraries that this project pulls into so many > > dependency trees. There's been some discussion of a 2.0 release in > > JIra at https://issues.apache.org/jira/projects/LOGGING/issues/LOGGING-187 > > but I'd lik to bring this to a wider audience. Specifically my > > thoughts are: > > > > 1. 2.0 will be technically API incompatible since it will remove all > > traces of EOL libraries like log4j 1.x and avalon. > > 2. It will otherwise be a drop-in replacement for anyone not using > > these old libraries. Specifically: > > * Other deprecated methods are not removed. > > * The package name does not change. > > * The group ID and artifact ID do not change. > > * Minimum Java version remains 1.8 > > 3. It can include any recent, API compatible bug fixes and new > > features that are available at HEAD, but these are not blockers. > > > > While there are other more incompatible changes that could be made in > > a major version bump, I think it's really important to produce a > > drop-in replacement that is friendlier to security scanners and > > dependency analyzers. I do not want to discourage people from > > upgrading for any reason other than they're still using EOL libraries > > like log4j 1.x. > > > > 1.3.0 was recently released and seems up to date with the last several > > years of changes and bugs, so it feels like a good time to make the > > break. Anyone who isn't ready to give up their decade+ old loggers can > > stay on this release for a while. However if there's a strong need to > > maintain a 1.x branch that could be done too. Or we could start 2.x > > as a separate branch. > > > > If this achieves rough consensus, I can start sending PRs. However, > > the final release would require a commons committer or perhaps PMC > > member to take over. > > > > Thoughts? > > > > -- > > Elliotte Rusty Harold > > elh...@ibiblio.org > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [LOGGING] 2.0
Below. On Sat, Feb 10, 2024 at 12:11 PM sebb wrote: > > On Sat, 10 Feb 2024 at 16:27, Gary Gregory wrote: > > > > Hi All: > > > > I want to focus on content before we decide what label to put on the > > next release. Then, we can see if we want to break binary > > compatibility (BC) for a Commons Logging 2.0.0. > > > > 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. > > > > 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. > > 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. > > Isn't that much the same as re-implementing option 1? Of course, but it would be the direct path. > > > 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 > > 4) A gutting of Log4JLogger where all methods are no-ops. > > Surely it would be better to throw an Exception rather than > silently drop what could be important info? That's option 5) ;-) if it's OK to blow up apps ;-) Gary > > > This maintains BC and can become 1.4.0. > > I like (1) the best, it gives us a clear path to a 1.4.0 without > > breaking BC and removes dependencies on the 1.x jars. > > From my POV breaking BC in Logging 1.x is a non-starter. > > > > Then, if we want to remove support for the Log4j 1 API (the JAR is > > already gone at this point), that would necessitate a 2.0.0. > > > > Gary > > > > On Sat, Feb 10, 2024 at 8:53 AM Elliotte Rusty Harold > > wrote: > > > > > > I'd like to plan and start working on a 2.0 release of commons-logging > > > with the specific goal of resolving the large number of out of date, > > > unsupported, old libraries that this project pulls into so many > > > dependency trees. There's been some discussion of a 2.0 release in > > > JIra at https://issues.apache.org/jira/projects/LOGGING/issues/LOGGING-187 > > > but I'd lik to bring this to a wider audience. Specifically my > > > thoughts are: > > > > > > 1. 2.0 will be technically API incompatible since it will remove all > > > traces of EOL libraries like log4j 1.x and avalon. > > > 2. It will otherwise be a drop-in replacement for anyone not using > > > these old libraries. Specifically: > > > * Other deprecated methods are not removed. > > > * The package name does not change. > > > * The group ID and artifact ID do not change. > > > * Minimum Java version remains 1.8 > > > 3. It can include any recent, API compatible bug fixes and new > > > features that are available at HEAD, but these are not blockers. > > > > > > While there are other more incompatible changes that could be made in > > > a major version bump, I think it's really important to produce a > > > drop-in replacement that is friendlier to security scanners and > > > dependency analyzers. I do not want to discourage people from > > > upgrading for any reason other than they're still using EOL libraries > > > like log4j 1.x. > > > > > > 1.3.0 was recently released and seems up to date with the last several > > > years of changes and bugs, so it feels like a good time to make the > > > break. Anyone who isn't ready to give up their decade+ old loggers can > > > stay on this release for a while. However if there's a strong need to > > > maintain a 1.x branch that could be done too. Or we could start 2.x > > > as a separate branch. > > > > > > If this achieves rough consensus, I can start sending PRs. However, > > > the final release would require a commons committer or perhaps PMC > > > member to take over. > > > > > > Thoughts? > > > > > > -- > > > Elliotte Rusty Harold > > > elh...@ibiblio.org > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > --
Re: [LOGGING] 2.0
Experiment for (1): https://github.com/garydgregory/commons-logging/tree/log4j1-log42-api Yes, I know there are test failures (they make sense, and that needs adjusting). Gary On Sat, Feb 10, 2024 at 11:26 AM Gary Gregory wrote: > > Hi All: > > I want to focus on content before we decide what label to put on the > next release. Then, we can see if we want to break binary > compatibility (BC) for a Commons Logging 2.0.0. > > 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. > > 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. > 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. > 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 > 4) A gutting of Log4JLogger where all methods are no-ops. > This maintains BC and can become 1.4.0. > > I like (1) the best, it gives us a clear path to a 1.4.0 without > breaking BC and removes dependencies on the 1.x jars. > From my POV breaking BC in Logging 1.x is a non-starter. > > Then, if we want to remove support for the Log4j 1 API (the JAR is > already gone at this point), that would necessitate a 2.0.0. > > Gary > > On Sat, Feb 10, 2024 at 8:53 AM Elliotte Rusty Harold > wrote: > > > > I'd like to plan and start working on a 2.0 release of commons-logging > > with the specific goal of resolving the large number of out of date, > > unsupported, old libraries that this project pulls into so many > > dependency trees. There's been some discussion of a 2.0 release in > > JIra at https://issues.apache.org/jira/projects/LOGGING/issues/LOGGING-187 > > but I'd lik to bring this to a wider audience. Specifically my > > thoughts are: > > > > 1. 2.0 will be technically API incompatible since it will remove all > > traces of EOL libraries like log4j 1.x and avalon. > > 2. It will otherwise be a drop-in replacement for anyone not using > > these old libraries. Specifically: > > * Other deprecated methods are not removed. > > * The package name does not change. > > * The group ID and artifact ID do not change. > > * Minimum Java version remains 1.8 > > 3. It can include any recent, API compatible bug fixes and new > > features that are available at HEAD, but these are not blockers. > > > > While there are other more incompatible changes that could be made in > > a major version bump, I think it's really important to produce a > > drop-in replacement that is friendlier to security scanners and > > dependency analyzers. I do not want to discourage people from > > upgrading for any reason other than they're still using EOL libraries > > like log4j 1.x. > > > > 1.3.0 was recently released and seems up to date with the last several > > years of changes and bugs, so it feels like a good time to make the > > break. Anyone who isn't ready to give up their decade+ old loggers can > > stay on this release for a while. However if there's a strong need to > > maintain a 1.x branch that could be done too. Or we could start 2.x > > as a separate branch. > > > > If this achieves rough consensus, I can start sending PRs. However, > > the final release would require a commons committer or perhaps PMC > > member to take over. > > > > Thoughts? > > > > -- > > Elliotte Rusty Harold > > elh...@ibiblio.org > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [LOGGING] 2.0
I'm fine with #1 or #2 if you can make either work. I actively dislike #3. In particular I do not think we should change package names or Maven coordinates. I think it is OK and in this case highly advisable to break API compatibility solely by removing support for obsolete and mostly unused functionality. It is much more important to keep the API for the actively and widely used API intact. That includes package names and Maven coordinates. Changing these makes upgrading to the newer version far more burdensome. Many projects won't do it, and most won't do it quickly. #4 strikes me as excessively nit-picky. If you're going to turn all methods into no-ops, you might as well remove the API. At least then clients of these APIs know their code is broken. Log4J 1.x is not the only thing we need to cut out. We also need to remove AvalonLogger and Jdk13LumberjackLogger, but if you can remove log4j 1.x in commons-logging 1.4 without breaking things that's a step in the right direction. Otherwise, I propose dropping AvalonLogger, Jdk13LumberjackLogger, and Log4jLogger; and shipping what's left as 2.0. On Sat, Feb 10, 2024 at 4:27 PM Gary Gregory wrote: > > Hi All: > > I want to focus on content before we decide what label to put on the > next release. Then, we can see if we want to break binary > compatibility (BC) for a Commons Logging 2.0.0. > > 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. > > 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. > 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. > 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 > 4) A gutting of Log4JLogger where all methods are no-ops. > This maintains BC and can become 1.4.0. > > I like (1) the best, it gives us a clear path to a 1.4.0 without > breaking BC and removes dependencies on the 1.x jars. > From my POV breaking BC in Logging 1.x is a non-starter. > > Then, if we want to remove support for the Log4j 1 API (the JAR is > already gone at this point), that would necessitate a 2.0.0. > > Gary > > On Sat, Feb 10, 2024 at 8:53 AM Elliotte Rusty Harold > wrote: > > > > I'd like to plan and start working on a 2.0 release of commons-logging > > with the specific goal of resolving the large number of out of date, > > unsupported, old libraries that this project pulls into so many > > dependency trees. There's been some discussion of a 2.0 release in > > JIra at https://issues.apache.org/jira/projects/LOGGING/issues/LOGGING-187 > > but I'd lik to bring this to a wider audience. Specifically my > > thoughts are: > > > > 1. 2.0 will be technically API incompatible since it will remove all > > traces of EOL libraries like log4j 1.x and avalon. > > 2. It will otherwise be a drop-in replacement for anyone not using > > these old libraries. Specifically: > > * Other deprecated methods are not removed. > > * The package name does not change. > > * The group ID and artifact ID do not change. > > * Minimum Java version remains 1.8 > > 3. It can include any recent, API compatible bug fixes and new > > features that are available at HEAD, but these are not blockers. > > > > While there are other more incompatible changes that could be made in > > a major version bump, I think it's really important to produce a > > drop-in replacement that is friendlier to security scanners and > > dependency analyzers. I do not want to discourage people from > > upgrading for any reason other than they're still using EOL libraries > > like log4j 1.x. > > > > 1.3.0 was recently released and seems up to date with the last several > > years of changes and bugs, so it feels like a good time to make the > > break. Anyone who isn't ready to give up their decade+ old loggers can > > stay on this release for a while. However if there's a strong need to > > maintain a 1.x branch that could be done too. Or we could start 2.x > > as a separate branch. > > > > If this achieves rough consensus, I can start sending PRs. However, > > the final release would require a commons committer or perhap
Re: [LOGGING] 2.0
Hi Gary, On Sat, 10 Feb 2024 at 17:26, Gary Gregory 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
