Re: [log4j] Remove `` in `main`

[Volkan Yazıcı]

I agree with your remark on priority. Using Log4j 2 API in Log4j 3 is
indeed our focus. My recent refactoring of `StatusLogger` was a part of
that effort. Since I already have my hands dirty with it, I want to take
one last step to polish it in `main` and remove the `StatusConfiguration`
wrinkle.

As soon as I have time, I will land two PRs:

   1. One against `2.x` to warn that `StatusConfiguration` will be removed
   2. One against `main` to remove the `StatusConfiguration`

I also agree that having `StatusLogger` per `LoggerContext` is an overkill
and I am strongly opinionated on that.

On Wed, Feb 14, 2024 at 4:34 AM Ralph Goers 
wrote:

> There could be if there was a StatusLogger per LoggerContext. But you
> would still need a global StatusLogger. But doing that seems like overkill.
>
> On the one hand it is very convenient to configure the level in the config
> file, but on the other the fact that it only takes place halfway through
> configuration is a bit of a problem as that is largely when it is needed.
>
> There is also the issue of compatibility. If support for it is removed we
> would still need to tolerate its presence. In the beginning we could log an
> Info message and then after a while convert it to a warn message before
> support is removed.
>
> To be honest, this isn’t a top priority on the list of things that need to
> be addressed for me which is partly why I guess I am hesitant to do
> anything. It feels like we keep talk about making changes but aren’t really
> focused on getting 3.0 done. Of course, deciding to stick with the 2.x API
> threw a wrinkle into the works of getting 3.x out the door but I’d still
> like that to be our top focus.
>
> Ralph
>
> > On Feb 13, 2024, at 10:21 AM, Matt Sicker  wrote:
> >
> > If there were a way to allow for multiple StatusLogger configurations
> concurrently, then I’d support keeping it in the config file. Otherwise,
> I’m somewhat ambivalent about this.
> >
> >> On Feb 12, 2024, at 13:29, Volkan Yazıcı  wrote:
> >>
> >> *Abstract:* I want to remove from `main` the feature that a
> `Configuration`
> >> (e.g., `` in a `log4j2.xml`)
> >> configuring the `StatusLogger`, and instead, only allow configuration
> using
> >> properties.
> >>
> >> `StatusLogger` can be configured in following ways:
> >>
> >>  1. Passing system properties to the Java process (e.g.,
> >>  `-Dlog4j2.StatusLogger.level=INFO`)
> >>  2. Providing properties in a `log4j2.StatusLogger.properties` file in
> >>  the classpath
> >>  3. Using Log4j configuration (i.e., ` >>  dest="out">`) in a `log4j2.xml` in the classpath. This is facilitated
> by
> >>  `StatusConfiguration`.
> >>  4. Programmatically (i.e., `StatusLogger.getLogger().setLevel(...)`)
> >>
> >> `StatusConfiguration`-based configuration has certain caveats:
> >>
> >>  - There is a time between the first `StatusLogger` access and a
> >>  configuration file (e.g., `log4j2.xml`) read. Hence, there is a time
> window
> >>  that only the defaults will be effective.
> >>  - `StatusConfiguration` is created per `LoggerContext` and each LC
> >>  mutates the (globally shared!) `StatusLogger`. Hence, the last loaded
> >>  configuration always becomes the effective one.
> >>
> >> Given the purpose of `StatusLogger` (i.e., the logger of the logging
> >> system) and above shortcomings related to `StatusConfiguration`, I want
> to
> >> remove the `StatusConfiguration`-based configuration in `main`.
> Thoughts?
> >> Objections?
> >
>
>

Re: [log4j] Remove `` in `main`

[Piotr P. Karwasz]

Hi Ralph,

On Wed, 14 Feb 2024 at 04:35, Ralph Goers  wrote:
> To be honest, this isn’t a top priority on the list of things that need to be 
> addressed for me which is partly why I guess I am hesitant to do anything. It 
> feels like we keep talk about making changes but aren’t really focused on 
> getting 3.0 done. Of course, deciding to stick with the 2.x API threw a 
> wrinkle into the works of getting 3.x out the door but I’d still like that to 
> be our top focus.

Believe me, 3.0 is our top focus. I can make a release of beta2 this
week, before we rebase `log4j-core` on top of `log4j-api` 2.x.

These are just small detours and curiosity that we find, while we pass
the main 3.x code through a comble.

Piotr

Re: Version 2.23.0 release schedule

[Gary Gregory]

FYI, the 1.2 bridge is fixed now. Not sure if the bug is present or not for
JUL.

Gary

On Mon, Feb 12, 2024, 8:07 AM Piotr P. Karwasz 
wrote:

> Hi Gary,
>
> On Mon, 12 Feb 2024 at 13:22, Gary Gregory  wrote:
> >
> > I'll continue later today to try and fix the set Level issue...
>
> Great! I have created a bug for that:
>
> https://github.com/apache/logging-log4j2/issues/2281
>
> Piotr
>

Re: Migrate *all* Issue Tracking and Discussions to GitHub

[Robert Middleton]

I have no strong feelings either way.  Turning on github discussions is a
good idea in my mind.

+0

-Robert Middleton

On Tue, Feb 13, 2024 at 12:45 PM Jan Friedrich 
wrote:

> +1 from me
>
> Jan
>
> XA> +1.
> XA> 
> XA> From: Matt Sicker 
> XA> Sent: Wednesday, February 14, 2024 1:22:48 AM
> XA> To: Apache Logging Developers List 
> XA> Subject: Re: Migrate *all* Issue Tracking and Discussions to GitHub
>
> XA> I think it’s a good idea, especially since Jira registrations are
> closed.
>
> >> On Feb 13, 2024, at 02:20, Volkan Yazıcı  wrote:
> >>
> >> Log4j has deprecated JIRA in favor of GitHub Issues and enabled GitHub
> >> Discussions as an alternative (not replacement!) to mailing lists. So
> far
> >> it has been a great success[1]. I suggest doing the same for Log4cxx and
> >> Log4net too. Thoughts? Objections?
> >>
> >> Note that I am not talking about only enabling these features. But to
> >> actively promote them on the website too. Check out the Log4j support
> page
> >>  for an example.
> >>
> >> [1] Code was already on GitHub. Now we can refer to PRs, issues,
> commits,
> >> code blocks, etc. while having conversations on any GitHub text input. I
> >> find this quite convenient. IMO, as a result of this convenience, I see
> way
> >> more maintainer engagement in PRs and issues. Next to that, GitHub
> >> Discussions clearly enabled more user interactions. It works around the
> >> mailing list subscription barrier.
>
>

Re: Migrate *all* Issue Tracking and Discussions to GitHub

[Gary Gregory]

Keep in mind that decisions for the project still must be recorded on the
mailing list. This might be a silly reminder since the issue is the same
with Jira. Let's just be mindful of this information tracking as we've
moved more of our infrastructure to GitHub. Don't get me wrong, I love
working with GitHub, I just want to make sure that we play by our Apache
rules.

Gary

On Wed, Feb 14, 2024, 8:47 AM Robert Middleton 
wrote:

> I have no strong feelings either way.  Turning on github discussions is a
> good idea in my mind.
>
> +0
>
> -Robert Middleton
>
> On Tue, Feb 13, 2024 at 12:45 PM Jan Friedrich  >
> wrote:
>
> > +1 from me
> >
> > Jan
> >
> > XA> +1.
> > XA> 
> > XA> From: Matt Sicker 
> > XA> Sent: Wednesday, February 14, 2024 1:22:48 AM
> > XA> To: Apache Logging Developers List 
> > XA> Subject: Re: Migrate *all* Issue Tracking and Discussions to GitHub
> >
> > XA> I think it’s a good idea, especially since Jira registrations are
> > closed.
> >
> > >> On Feb 13, 2024, at 02:20, Volkan Yazıcı  wrote:
> > >>
> > >> Log4j has deprecated JIRA in favor of GitHub Issues and enabled GitHub
> > >> Discussions as an alternative (not replacement!) to mailing lists. So
> > far
> > >> it has been a great success[1]. I suggest doing the same for Log4cxx
> and
> > >> Log4net too. Thoughts? Objections?
> > >>
> > >> Note that I am not talking about only enabling these features. But to
> > >> actively promote them on the website too. Check out the Log4j support
> > page
> > >>  for an example.
> > >>
> > >> [1] Code was already on GitHub. Now we can refer to PRs, issues,
> > commits,
> > >> code blocks, etc. while having conversations on any GitHub text
> input. I
> > >> find this quite convenient. IMO, as a result of this convenience, I
> see
> > way
> > >> more maintainer engagement in PRs and issues. Next to that, GitHub
> > >> Discussions clearly enabled more user interactions. It works around
> the
> > >> mailing list subscription barrier.
> >
> >
>

Re: Migrate *all* Issue Tracking and Discussions to GitHub

[Volkan Yazıcı]

As per consensus, enabled GitHub Discussions for both Log4Net and Log4cxx –
GitHub Issues were already enabled. I will submit a PR to both projects
updating their docs to reflect these changes.

On Tue, Feb 13, 2024 at 9:20 AM Volkan Yazıcı  wrote:

> Log4j has deprecated JIRA in favor of GitHub Issues and enabled GitHub
> Discussions as an alternative (not replacement!) to mailing lists. So far
> it has been a great success[1]. I suggest doing the same for Log4cxx and
> Log4net too. Thoughts? Objections?
>
> Note that I am not talking about only enabling these features. But to
> actively promote them on the website too. Check out the Log4j support page
>  for an example.
>
> [1] Code was already on GitHub. Now we can refer to PRs, issues, commits,
> code blocks, etc. while having conversations on any GitHub text input. I
> find this quite convenient. IMO, as a result of this convenience, I see way
> more maintainer engagement in PRs and issues. Next to that, GitHub
> Discussions clearly enabled more user interactions. It works around the
> mailing list subscription barrier.
>

Re: [VOTE] Move Chainsaw to dormant

[Carter Kozak]

+1

Thanks!
-ck

On Mon, Feb 12, 2024, at 16:31, Christian Grobmeier wrote:
> This vote is to put Chainsaw to the "Dormant" components. There is much work 
> to be done on this component, but not enough hours can be committed to do 
> that work. To reflect this situation to the user, it is better to move 
> Chainsaw to the dormant section and communicate it as "no longer maintained." 
>  The component can be moved back to the "active" state whenever people are 
> actively working on it. The main branch in the repository will be marked with 
> the new state, but the repository will not be archived for now.
> 
> Please note:
> 
> [ ] +1, move to dormant
> [ ]  -1, don't because...
> 
> I will leave this vote open for the usual 72 hours.