Gary,

The work for this was covered in LOG4J2-2621 which was resolved in 
June 2019 and discussed on the dev list a few times. It is a little late to 
be asking that question.

Ralph

> On Mar 28, 2022, at 12:20 PM, Gary Gregory <garydgreg...@gmail.com> wrote:
> 
> Hi Matt,
> 
> Why isn't the code in log4-plugins in log4j-core?
> 
> Gary
> 
> On Sun, Mar 27, 2022, 16:59 Matt Sicker <boa...@gmail.com> wrote:
> 
>> Hey all, after making a lot of serious progress toward what I’ve been
>> alternatively referring to as the “Mean Bean Machine” or the “Great
>> Inversion”, I’m finally coming to a logical conclusion of this (only have a
>> couple remaining plugin types to refactor). While it took a few tries using
>> different APIs and approaches to using dependency injection, I’m feeling
>> good about this current iteration as it’s been fairly successful so far at
>> applying inversion of control to places that were otherwise using ad hoc
>> configuration mechanisms or other static method factories to enable a
>> unified approach to configuring things.
>> 
>> With this in place, I believe we only have a few remaining high level
>> tasks to complete before we can release 3.0.0 (including any potential
>> early-release alpha/beta versions). Please feel free to comment on any of
>> these or add other items.
>> 
>> * The log4j-core module still needs to be further broken into modules such
>> that log4j-core only requires java.base (and log4j-api and log4j-plugins).
>> * The rest of the Log4j modules that don’t already have a module-info.java
>> file need one.
>> * There are dozens (possibly hundreds) of commits that have only been
>> applied to release-2.x which need to be copied to master.
>> * The new JSON configuration factory based on an embedded JSON parser
>> (from the JSON Template Layout module) needs to be merged into log4j-core
>> to replace the Jackson variant (which would be moved to its own module just
>> like the other configuration factories that require more than java.base).
>> * The LoggerContext properties configuration proposal from Ralph needs to
>> be implemented.
>> * The website and docs need to be updated, though this task is shared with
>> the same issue for 2.x.
>> 
>> Based on these remaining issues to resolve, I’d estimate that we can most
>> likely make a 3.0.0 release before ApacheCon this year (which is Oct 3-6)
>> which could make great timing for getting a talk or two accepted at
>> ApacheCon (the first and last time I had a talk accepted for this was for
>> the 2.0 release). If that’s the case, then I also have a tentative schedule
>> we can try to follow:
>> 
>> 1. Make an alpha or beta release of 3.0.0 by June.
>> 2. Preferably more than one beta depending on feedback.
>> 3. Work on cutting 3.0.0 by September.
>> 
>> Hopefully this timeline isn’t overly optimistic, but I believe we’ve
>> finally passed some of the toughest parts of the roadmap (Java modules and
>> the Great Inversion being two of them). It’d also be great to try to have a
>> Log4j release with a Java 11 baseline before Java 11 itself is EOL, but
>> that’s not a _requirement_ per se.
>> —
>> Matt Sicker
>> 
>> 

Reply via email to