I’m confused. 3.0.0 hasn’t even been released so how can I be preventing adding anything. Personally I would prefer the monitoring to be in a separate repo but I am ok with adding it to the main build. IAM all for moving async out but unless it can be done quickly I’d rather do it in a future 3.x release. The same is generally true for your other bullets as well.
The point of alphas and betas is to find regressions. We need to fix them. Ralph > On Nov 2, 2023, at 1:17 AM, Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: > > 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
