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

Reply via email to