Hi Ralph, On Thu, 2 Nov 2023 at 08:39, Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: > Hi Ralph, > On Thu, 2 Nov 2023 at 05:53, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > JPMS is not the main target for 2.x as 2.x still supports Java 8 and has to > > use “versioned” jars so it can work in Java 8 and Java 11+. 3.x only > > supports Java 11 and is really where we want to focus our attention. I wish > > everyone would agree with this so we could get 3.0.0 GA out as quickly as > > possible but people still want to (seemingly endlessly) tinker with 3.x. > > Once 3.x I would like to announce that 2.x’s EOL is directly tied to the > > longevity of Java 8. Once Java 8 falls below 10% usage it will be EOL’d. > > So I would rather everyone focus their energy on 3.x and not make any more > > changes to 2.x other than bug-fixes.
I agree that 3.x should have a fixed number of features. We should probably agree on them and close the list. There are things that I would like to add to 3.x, that you won't allow me to do in a minor release: * drop JMX support in 3.0.x: I have a basic understanding on how Micrometer works. In 3.1.x I could restore the monitoring capabilities of Log4j Core with a `log4j-core-jmx` module and possibly a `log4j-core-micrometer` module (or `micrometer-log4j-core` if the Micrometer project accepts such a contribution). This could probably be done by just extending the public `log4j-core` API, * move the code that depends on LMAX disruptor to a separate module (`log4j-async-logger`, but I am open to suggestions for a better name), * move the code that depends on Conversant disruptor to a separate module (`log4j-async-queue-disruptor` for lack of a better name), * move the code that depends on JCTools to a separate module (`log4j-async-queue-jctools`); the same applies to JTL, * move the code that depends on Commons Compress to a separate module (`log4j-file-compress`), * move the code that depends on JAnsi to a separate module (`log4j-console-jansi`), * remove the Jackson-based configuration factories (to be restored in 3.1.x) or move them to a different module, * remove the `log4j-jndi` dependency from `log4j-jdbc` by creating `log4j-jdbc-jndi`. * drop `log4j-slf4j-impl`, since as far as I know the 1.7.x branch is not supported any more by Ceki; I know this contains some support for structured events from `slf4j-ext` 1.7.25 that is not present in `log4j-slfj42-impl`, but I suppose this is no longer needed. There are some changes we are waiting for (https://github.com/apache/logging-log4j2/milestone/2): * LoggerContext-scoped properties, plugins, etc. I am not sure we can introduce this in a minor release. I recently extended JCL to use the Log4j API and SLF4J and noticed that Logback does not allow multiple logger contexts. We do, but those are useless if Log4j Core in the system classloader can't pick up plugins from other classloaders. A little example: in Tomcat the system classloader basically contains only the logging framework and `log4j-core` can not pick up `log4j-web` in the classloader with all the Servlet API classes, * Recycler API: I doubt we can introduce a uniform way to cache objects without breaking changes. Volkan will pick this up shortly, so be patient, * regressions, regressions and once again regressions. One is even reported (https://github.com/apache/logging-log4j2/issues/1439) and has been sitting there for some time. Piotr
