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