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