Re: The roadmap to Log4j 3.0.0

[Ralph Goers]

Yes, I would really like to see the plugin system moved to something like 
Commons Plugins. Of course, it would be even better as javax.plugins!  Of 
course, moving it does mean users will now be required to include log4j-plugins 
in addition to log4j-api and log4j-core. However, I don’t necessarily see that 
is a bad thing given how many more jars log4j 3.x is going to have.

Ralph

> On Mar 28, 2022, at 12:32 PM, Matt Sicker  wrote:
> 
> Originally, it was because most of that code had to be there where the 
> annotations were. Now some of that code can be moved back to core, though 
> some of it would still need to remain for the annotation processing stuff. 
> Ralph had suggested recently that the plugin code could form a useful basis 
> for other projects like Flume, too, which itself might make sense in Commons, 
> but otherwise, it’s still mainly in the plugins module out of convenience 
> (core tests take too long for rapid iteration of the DI system, but now that 
> it’s in place, it’s not as necessary).
> 
> —
> Matt Sicker
> 
>> On Mar 28, 2022, at 14:21, Gary Gregory  wrote:
>> 
>> Hi Matt,
>> 
>> Why isn't the code in log4-plugins in log4j-core?
>> 
>> Gary
>> 
>>> On Sun, Mar 27, 2022, 16:59 Matt Sicker  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
>>> 
>>> 

Re: The roadmap to Log4j 3.0.0

[Ralph Goers]

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  wrote:
> 
> Hi Matt,
> 
> Why isn't the code in log4-plugins in log4j-core?
> 
> Gary
> 
> On Sun, Mar 27, 2022, 16:59 Matt Sicker  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
>> 
>> 

Re: The roadmap to Log4j 3.0.0

[Gary Gregory]

It's just a question, not a request.

Gary

On Tue, Mar 29, 2022, 03:31 Ralph Goers  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 
> wrote:
> >
> > Hi Matt,
> >
> > Why isn't the code in log4-plugins in log4j-core?
> >
> > Gary
> >
> > On Sun, Mar 27, 2022, 16:59 Matt Sicker  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
> >>
> >>
>
>

Re: The roadmap to Log4j 3.0.0

[Matt Sicker]

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  wrote:
> 
> It's just a question, not a request.
> 
> Gary
> 
>> On Tue, Mar 29, 2022, 03:31 Ralph Goers  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 
>> wrote:
>>> 
>>> Hi Matt,
>>> 
>>> Why isn't the code in log4-plugins in log4j-core?
>>> 
>>> Gary
>>> 
 On Sun, Mar 27, 2022, 16:59 Matt Sicker  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
 
 
>> 
>> 

Developers, mailing lists, etc. in `pom.xml`

[Volkan Yazıcı]

Today we had a chat with Christian and we are inclined to remove (when
proceeding with the revamping of the site generation gig of mine) the
following information from pom.xml files:

   - issueManagement (Why would anybody check pom.xml for this? We have a
   website and README pointing to JIRA for issues.)
   - ciManagement (Again, why pom.xml? Not to mention the information here
   still points to Jenkins.)
   - developers & contributors (Rather than maintaining developers in every
   single pom.xml, we should stick to a single source: Apache Logging
   Services Project Team page .)
   - mailingLists (Again, we have an Apache Logging Services Mailing lists
   page .)

Objections? Thoughts?

Re: Developers, mailing lists, etc. in `pom.xml`

[Ralph Goers]

That stuff is all there because the site plugin requires it. Once we aren’t 
using that I am fine with pulling it.

Ralph

> On Mar 29, 2022, at 12:46 PM, Volkan Yazıcı  wrote:
> 
> Today we had a chat with Christian and we are inclined to remove (when
> proceeding with the revamping of the site generation gig of mine) the
> following information from pom.xml files:
> 
>   - issueManagement (Why would anybody check pom.xml for this? We have a
>   website and README pointing to JIRA for issues.)
>   - ciManagement (Again, why pom.xml? Not to mention the information here
>   still points to Jenkins.)
>   - developers & contributors (Rather than maintaining developers in every
>   single pom.xml, we should stick to a single source: Apache Logging
>   Services Project Team page .)
>   - mailingLists (Again, we have an Apache Logging Services Mailing lists
>   page .)
> 
> Objections? Thoughts?