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 > >> > >> > >
