I don’t know if any new javax APIs are defined anymore. There’s JakartaEE for 
the new APIs, though that’s through Eclipse at this point I think.

Also, for a generic plugin library, there are some things I’d likely do 
slightly differently than in here since backward compatibility wouldn’t be 
relevant. Though that behavior itself could potentially be customizable.

—
Matt Sicker

> On Mar 29, 2022, at 07:45, Gary Gregory <garydgreg...@gmail.com> wrote:
> 
> It's just a question, not a request.
> 
> Gary
> 
>> On Tue, Mar 29, 2022, 03:31 Ralph Goers <ralph.go...@dslextreme.com> wrote:
>> 
>> 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