Re: Resurrecting log4j 1.x

[Remko Popma]

Vladimir,

There is a vote thread in progress (
https://lists.apache.org/thread/0rk0nr0pv9p2945jsrs9pp2ys57wksn3). You and
I both voted on that thread.
Looking at the number of +1 votes on that voting thread, surely you can see
that this repo will be created, and not only that, it will be created
*exactly the way you asked for*.
As far as I can see, there is no missing bit any more.

So, maybe I am missing something, but I cannot see the point of your
message to Christian.
Why use harsh words to push for something that is already happening?

Personally I enjoy being on the Logging PMC because we have a nice
community where people really listen and are careful how they phrase things.
I think we truly try to embody Apache's code of conduct
 as well as
the participation
guidelines  in all our
communications.

We are all only human, doing the best we can.
Let's be kind to each other.

Remko


On Fri, Dec 24, 2021 at 2:30 PM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> Christian>Here is some more information on how we develop software:
>
> Christian, I'm a member of PMC in Apache JMeter and Apache Calcite, ok?
>
> >as a community, need to find consensus first
>
> Could you please stop going in circles and just agree to open apache/log4j
> Git for writes?
> Are there another viable alternatives?
>
> 14 December I suggest shipping 1.2.18
> 16 December I started "[VOTE] Move log4j 1.x from SVN to Git, use the
> current apache/log4j mirror"
> https://lists.apache.org/thread/ssbdg44gy7txzl16xxd097t7orco52g2
> ^^ this is exactly to gather PMC consensus on proceeding the work on log4j
> 1.x in apache/log4j git repo.
> As it turns out later, the email consensus on opening Git for writes was
> absolutely needed.
> lots of mails...
> 21 December Remko says "migration to Git will happen"
> https://lists.apache.org/thread/y463on8fbvkkc0k0wpzo68ywmogg6327
> Then, out of a sudden Ralph creates a new Git repo instead of continuing in
> the initially requested one.
>
> 23 December I create INFRA-22654 so Logging PMC understands that
> the only missing bit is their consensus on reopening apache/log4j
>
> Note, that INFRA says they can easily reopen apache/log4j, and the only
> missing bit
> is exactly the one I asked 16 December.
>
> Vladimir
>

Re: Resurrecting log4j 1.x

[Vladimir Sitnikov]

Christian>Here is some more information on how we develop software:

Christian, I'm a member of PMC in Apache JMeter and Apache Calcite, ok?

>as a community, need to find consensus first

Could you please stop going in circles and just agree to open apache/log4j
Git for writes?
Are there another viable alternatives?

14 December I suggest shipping 1.2.18
16 December I started "[VOTE] Move log4j 1.x from SVN to Git, use the
current apache/log4j mirror"
https://lists.apache.org/thread/ssbdg44gy7txzl16xxd097t7orco52g2
^^ this is exactly to gather PMC consensus on proceeding the work on log4j
1.x in apache/log4j git repo.
As it turns out later, the email consensus on opening Git for writes was
absolutely needed.
lots of mails...
21 December Remko says "migration to Git will happen"
https://lists.apache.org/thread/y463on8fbvkkc0k0wpzo68ywmogg6327
Then, out of a sudden Ralph creates a new Git repo instead of continuing in
the initially requested one.

23 December I create INFRA-22654 so Logging PMC understands that
the only missing bit is their consensus on reopening apache/log4j

Note, that INFRA says they can easily reopen apache/log4j, and the only
missing bit
is exactly the one I asked 16 December.

Vladimir

Re: [VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

[Remko Popma]

The Log4j1 project is EOL, and assuming that it remains EOL and we are only
doing security patches, I vote in favor of this repo change, to
facilitate making such security patches.
+1

I agree we need to get consensus on the scope of any Log4j1 work.

On Fri, Dec 24, 2021 at 8:53 AM Matt Sicker  wrote:

> I tend to agree here. Even if we go ahead with the repo rename, we’ll
> still need some consensus on the scope of this work.
> --
> Matt Sicker
>
> > On Dec 23, 2021, at 17:11, Christian Grobmeier 
> wrote:
> >
> > hi
> >
> > at the moment I am -1 too, mostly for the reasons Gary mentioned.
> > Most important is that we don't have a clear goal on what we are trying
> to achieve here. We should be very explicit of why we are doing what.
> >
> > Cheers,
> > Christian
> >
> >
> > On Thu, Dec 23, 2021, at 22:50, Gary Gregory wrote:
> >> -1
> >> We just created logging-log4j1 and converted the SVN repo into it, let's
> >> stick to that. I even made a commit ;-)
> >> I claim it is a good thing to start with a new repo because it creates a
> >> tiny bit of friction, for a project that is still End-of-Life after all.
> >> Even if it is a bit of friction to bring in old stuff from the old repo,
> >> this would provide a kind of effort/value filter.
> >> The concurrent consensus I see on the PMC is to fix the one listed CVE
> on
> >> our site plus other fixes in the style of the recent 2.x fixes.
> >> Bringing in all of the cruft from the old repo will give the wrong
> >> impression that we actually might be merging this or that random fix and
> >> feature. Which I claim is not the goal here.
> >>
> >> I feel we might need an addendum or a subsequent VOTE with a stated
> goal or
> >> charter for this repo to only provide CVE fixes (see above). Projects
> >> usually have a charter, not components I do not think, but I think we
> >> should have one here and put it in front and center in the README.md so
> we
> >> can manage expectations for people finding the repo on GitHub.
> >>
> >> Gary
> >>
> >> On Thu, Dec 23, 2021 at 4:35 PM Ralph Goers  >
> >> wrote:
> >>
> >>> In https://issues.apache.org/jira/browse/INFRA-22654 Chris Lambertus
> has
> >>> recommended that we can divorce
> >>> the read-only SVN repo from https://github.com/apache/log4j. However,
> it
> >>> will not be able to keep the same
> >>> name as all Git repos owned by the logging project must start with
> >>> “logging-“.
> >>>
> >>> So this vote is to:
> >>> 1. Delete the apache/logging-log4j1 repo I created last night.
> >>> 2. Divorce the apache/log4j repo from SVN.
> >>> 3. Rename apache/log4j to apache/logging-log4j1.
> >>> 4. Create a branch named “main” from the v1_2_17 tag.
> >>> 5. Make main the default branch in GitHub.
> >>>
> >>> While all votes are welcome Infra needs consensus from the PMC on this
> >>> vote so the result will separate
> >>> binding from non-binding votes.
> >>>
> >>> Ralph
> >>>
> >>> PS - I’ve separated this from the previous vote thread since it was
> mostly
> >>> discussion. If you want to discuss
> >>> this please prefix the subject with [DISCUSS]
>
>

Re: [DISCUSS][VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

[Remko Popma]

The Log4j1 project is EOL, and assuming that it remains EOL and we are only
doing security patches, I vote in favor of this repo change, to
facilitate making such security patches.
+1

I agree we need to get consensus on the scope of any Log4j1 work.


On Fri, Dec 24, 2021 at 8:55 AM Ralph Goers 
wrote:

> That will be the next separate discussion and vote.
>
> Ralph
>
> > On Dec 23, 2021, at 4:53 PM, Matt Sicker  wrote:
> >
> > I tend to agree here. Even if we go ahead with the repo rename, we’ll
> still need some consensus on the scope of this work.
> > --
> > Matt Sicker
> >
> >> On Dec 23, 2021, at 17:11, Christian Grobmeier 
> wrote:
> >>
> >> hi
> >>
> >> at the moment I am -1 too, mostly for the reasons Gary mentioned.
> >> Most important is that we don't have a clear goal on what we are trying
> to achieve here. We should be very explicit of why we are doing what.
> >>
> >> Cheers,
> >> Christian
> >>
> >>
> >> On Thu, Dec 23, 2021, at 22:50, Gary Gregory wrote:
> >>> -1
> >>> We just created logging-log4j1 and converted the SVN repo into it,
> let's
> >>> stick to that. I even made a commit ;-)
> >>> I claim it is a good thing to start with a new repo because it creates
> a
> >>> tiny bit of friction, for a project that is still End-of-Life after
> all.
> >>> Even if it is a bit of friction to bring in old stuff from the old
> repo,
> >>> this would provide a kind of effort/value filter.
> >>> The concurrent consensus I see on the PMC is to fix the one listed CVE
> on
> >>> our site plus other fixes in the style of the recent 2.x fixes.
> >>> Bringing in all of the cruft from the old repo will give the wrong
> >>> impression that we actually might be merging this or that random fix
> and
> >>> feature. Which I claim is not the goal here.
> >>>
> >>> I feel we might need an addendum or a subsequent VOTE with a stated
> goal or
> >>> charter for this repo to only provide CVE fixes (see above). Projects
> >>> usually have a charter, not components I do not think, but I think we
> >>> should have one here and put it in front and center in the README.md
> so we
> >>> can manage expectations for people finding the repo on GitHub.
> >>>
> >>> Gary
> >>>
> >>> On Thu, Dec 23, 2021 at 4:35 PM Ralph Goers <
> ralph.go...@dslextreme.com>
> >>> wrote:
> >>>
>  In https://issues.apache.org/jira/browse/INFRA-22654 Chris Lambertus
> has
>  recommended that we can divorce
>  the read-only SVN repo from https://github.com/apache/log4j.
> However, it
>  will not be able to keep the same
>  name as all Git repos owned by the logging project must start with
>  “logging-“.
> 
>  So this vote is to:
>  1. Delete the apache/logging-log4j1 repo I created last night.
>  2. Divorce the apache/log4j repo from SVN.
>  3. Rename apache/log4j to apache/logging-log4j1.
>  4. Create a branch named “main” from the v1_2_17 tag.
>  5. Make main the default branch in GitHub.
> 
>  While all votes are welcome Infra needs consensus from the PMC on this
>  vote so the result will separate
>  binding from non-binding votes.
> 
>  Ralph
> 
>  PS - I’ve separated this from the previous vote thread since it was
> mostly
>  discussion. If you want to discuss
>  this please prefix the subject with [DISCUSS]
> >
> >
>
>

Re: [DISCUSS][VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

[Ralph Goers]

That will be the next separate discussion and vote.

Ralph

> On Dec 23, 2021, at 4:53 PM, Matt Sicker  wrote:
> 
> I tend to agree here. Even if we go ahead with the repo rename, we’ll still 
> need some consensus on the scope of this work.
> --
> Matt Sicker
> 
>> On Dec 23, 2021, at 17:11, Christian Grobmeier  wrote:
>> 
>> hi
>> 
>> at the moment I am -1 too, mostly for the reasons Gary mentioned.
>> Most important is that we don't have a clear goal on what we are trying to 
>> achieve here. We should be very explicit of why we are doing what.
>> 
>> Cheers,
>> Christian
>> 
>> 
>> On Thu, Dec 23, 2021, at 22:50, Gary Gregory wrote:
>>> -1
>>> We just created logging-log4j1 and converted the SVN repo into it, let's
>>> stick to that. I even made a commit ;-)
>>> I claim it is a good thing to start with a new repo because it creates a
>>> tiny bit of friction, for a project that is still End-of-Life after all.
>>> Even if it is a bit of friction to bring in old stuff from the old repo,
>>> this would provide a kind of effort/value filter.
>>> The concurrent consensus I see on the PMC is to fix the one listed CVE on
>>> our site plus other fixes in the style of the recent 2.x fixes.
>>> Bringing in all of the cruft from the old repo will give the wrong
>>> impression that we actually might be merging this or that random fix and
>>> feature. Which I claim is not the goal here.
>>> 
>>> I feel we might need an addendum or a subsequent VOTE with a stated goal or
>>> charter for this repo to only provide CVE fixes (see above). Projects
>>> usually have a charter, not components I do not think, but I think we
>>> should have one here and put it in front and center in the README.md so we
>>> can manage expectations for people finding the repo on GitHub.
>>> 
>>> Gary
>>> 
>>> On Thu, Dec 23, 2021 at 4:35 PM Ralph Goers 
>>> wrote:
>>> 
 In https://issues.apache.org/jira/browse/INFRA-22654 Chris Lambertus has
 recommended that we can divorce
 the read-only SVN repo from https://github.com/apache/log4j. However, it
 will not be able to keep the same
 name as all Git repos owned by the logging project must start with
 “logging-“.
 
 So this vote is to:
 1. Delete the apache/logging-log4j1 repo I created last night.
 2. Divorce the apache/log4j repo from SVN.
 3. Rename apache/log4j to apache/logging-log4j1.
 4. Create a branch named “main” from the v1_2_17 tag.
 5. Make main the default branch in GitHub.
 
 While all votes are welcome Infra needs consensus from the PMC on this
 vote so the result will separate
 binding from non-binding votes.
 
 Ralph
 
 PS - I’ve separated this from the previous vote thread since it was mostly
 discussion. If you want to discuss
 this please prefix the subject with [DISCUSS]
> 
> 

Re: [VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

[Matt Sicker]

I tend to agree here. Even if we go ahead with the repo rename, we’ll still 
need some consensus on the scope of this work.
--
Matt Sicker

> On Dec 23, 2021, at 17:11, Christian Grobmeier  wrote:
> 
> hi
> 
> at the moment I am -1 too, mostly for the reasons Gary mentioned.
> Most important is that we don't have a clear goal on what we are trying to 
> achieve here. We should be very explicit of why we are doing what.
> 
> Cheers,
> Christian
> 
> 
> On Thu, Dec 23, 2021, at 22:50, Gary Gregory wrote:
>> -1
>> We just created logging-log4j1 and converted the SVN repo into it, let's
>> stick to that. I even made a commit ;-)
>> I claim it is a good thing to start with a new repo because it creates a
>> tiny bit of friction, for a project that is still End-of-Life after all.
>> Even if it is a bit of friction to bring in old stuff from the old repo,
>> this would provide a kind of effort/value filter.
>> The concurrent consensus I see on the PMC is to fix the one listed CVE on
>> our site plus other fixes in the style of the recent 2.x fixes.
>> Bringing in all of the cruft from the old repo will give the wrong
>> impression that we actually might be merging this or that random fix and
>> feature. Which I claim is not the goal here.
>> 
>> I feel we might need an addendum or a subsequent VOTE with a stated goal or
>> charter for this repo to only provide CVE fixes (see above). Projects
>> usually have a charter, not components I do not think, but I think we
>> should have one here and put it in front and center in the README.md so we
>> can manage expectations for people finding the repo on GitHub.
>> 
>> Gary
>> 
>> On Thu, Dec 23, 2021 at 4:35 PM Ralph Goers 
>> wrote:
>> 
>>> In https://issues.apache.org/jira/browse/INFRA-22654 Chris Lambertus has
>>> recommended that we can divorce
>>> the read-only SVN repo from https://github.com/apache/log4j. However, it
>>> will not be able to keep the same
>>> name as all Git repos owned by the logging project must start with
>>> “logging-“.
>>> 
>>> So this vote is to:
>>> 1. Delete the apache/logging-log4j1 repo I created last night.
>>> 2. Divorce the apache/log4j repo from SVN.
>>> 3. Rename apache/log4j to apache/logging-log4j1.
>>> 4. Create a branch named “main” from the v1_2_17 tag.
>>> 5. Make main the default branch in GitHub.
>>> 
>>> While all votes are welcome Infra needs consensus from the PMC on this
>>> vote so the result will separate
>>> binding from non-binding votes.
>>> 
>>> Ralph
>>> 
>>> PS - I’ve separated this from the previous vote thread since it was mostly
>>> discussion. If you want to discuss
>>> this please prefix the subject with [DISCUSS]

Re: Log4J 1.x progress, pull request(s), plans

[Christian Grobmeier]

On Thu, Dec 23, 2021, at 16:39, Leo Simons wrote:
> On Thu, 23 Dec 2021 at 15:43, Christian Grobmeier 
> wrote:
>
>> I didn't see the PRs though - are they still local on your box?
>
>
> On the wrong repo and lacking a target branch:
>
> https://github.com/apache/log4j/pull/17
> https://github.com/apache/log4j/pull/16
>
> From
> https://github.com/lsimons/log4j

Thanks for the pointer!

> For #17 I have it split across a couple branches in my forked repo, that
> could be their own PRs, but was waiting for feedback and a writeable repo.
>
> I am not near a laptop now so won’t contribute code until mid next week.
> Hope someone can pick up where I left off.

Don't worry, actually I am taking a few off days too. :-)

Kind regards,
Christian

>
> Cheers!
>
> Leo

Re: [VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

[Christian Grobmeier]

hi

at the moment I am -1 too, mostly for the reasons Gary mentioned.
Most important is that we don't have a clear goal on what we are trying to 
achieve here. We should be very explicit of why we are doing what.

Cheers,
Christian


On Thu, Dec 23, 2021, at 22:50, Gary Gregory wrote:
> -1
> We just created logging-log4j1 and converted the SVN repo into it, let's
> stick to that. I even made a commit ;-)
> I claim it is a good thing to start with a new repo because it creates a
> tiny bit of friction, for a project that is still End-of-Life after all.
> Even if it is a bit of friction to bring in old stuff from the old repo,
> this would provide a kind of effort/value filter.
> The concurrent consensus I see on the PMC is to fix the one listed CVE on
> our site plus other fixes in the style of the recent 2.x fixes.
> Bringing in all of the cruft from the old repo will give the wrong
> impression that we actually might be merging this or that random fix and
> feature. Which I claim is not the goal here.
>
> I feel we might need an addendum or a subsequent VOTE with a stated goal or
> charter for this repo to only provide CVE fixes (see above). Projects
> usually have a charter, not components I do not think, but I think we
> should have one here and put it in front and center in the README.md so we
> can manage expectations for people finding the repo on GitHub.
>
> Gary
>
> On Thu, Dec 23, 2021 at 4:35 PM Ralph Goers 
> wrote:
>
>> In https://issues.apache.org/jira/browse/INFRA-22654 Chris Lambertus has
>> recommended that we can divorce
>> the read-only SVN repo from https://github.com/apache/log4j. However, it
>> will not be able to keep the same
>> name as all Git repos owned by the logging project must start with
>> “logging-“.
>>
>> So this vote is to:
>> 1. Delete the apache/logging-log4j1 repo I created last night.
>> 2. Divorce the apache/log4j repo from SVN.
>> 3. Rename apache/log4j to apache/logging-log4j1.
>> 4. Create a branch named “main” from the v1_2_17 tag.
>> 5. Make main the default branch in GitHub.
>>
>> While all votes are welcome Infra needs consensus from the PMC on this
>> vote so the result will separate
>> binding from non-binding votes.
>>
>> Ralph
>>
>> PS - I’ve separated this from the previous vote thread since it was mostly
>> discussion. If you want to discuss
>> this please prefix the subject with [DISCUSS]

Re: Resurrecting log4j 1.x

[Christian Grobmeier]

Hello Vladimir,

On Thu, Dec 23, 2021, at 20:58, Vladimir Sitnikov wrote:
> Christian>if you send in patches there are people who would apply them
>
> Thank you.
> Let us see what INFRA says regarding https://github.com/apache/log4j in
> https://issues.apache.org/jira/browse/INFRA-22654

This is not an infrastructure issue. As Chris (from Infra) explained, we, as a 
community, need to find consensus first.

In other words, we have to discuss all issues and problems and then make up a 
vote. Only PMC member votes are usually considered binding. Before we reach 
consensus, we should not create any issues - and extra work - for infra.

Here is some more information on how we develop software:
https://www.apache.org/theapacheway/index.html

kind regards,
Christian

>
> Vladimir

Re: [VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

[Robert Middleton]

+1


On Thu, Dec 23, 2021 at 4:55 PM Vladimir Sitnikov
 wrote:
>
> +1
>
> Please use the existing apache/log4j repository, and rename it accordingly
>
> Vladimir

Re: [VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

[Vladimir Sitnikov]

+1

Please use the existing apache/log4j repository, and rename it accordingly

Vladimir

Re: [VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

[Matt Sicker]

These are some good points, Gary.
--
Matt Sicker

> On Dec 23, 2021, at 15:50, Gary Gregory  wrote:
> 
> -1
> We just created logging-log4j1 and converted the SVN repo into it, let's
> stick to that. I even made a commit ;-)
> I claim it is a good thing to start with a new repo because it creates a
> tiny bit of friction, for a project that is still End-of-Life after all.
> Even if it is a bit of friction to bring in old stuff from the old repo,
> this would provide a kind of effort/value filter.
> The concurrent consensus I see on the PMC is to fix the one listed CVE on
> our site plus other fixes in the style of the recent 2.x fixes.
> Bringing in all of the cruft from the old repo will give the wrong
> impression that we actually might be merging this or that random fix and
> feature. Which I claim is not the goal here.
> 
> I feel we might need an addendum or a subsequent VOTE with a stated goal or
> charter for this repo to only provide CVE fixes (see above). Projects
> usually have a charter, not components I do not think, but I think we
> should have one here and put it in front and center in the README.md so we
> can manage expectations for people finding the repo on GitHub.
> 
> Gary
> 
> On Thu, Dec 23, 2021 at 4:35 PM Ralph Goers 
> wrote:
> 
>> In https://issues.apache.org/jira/browse/INFRA-22654 Chris Lambertus has
>> recommended that we can divorce
>> the read-only SVN repo from https://github.com/apache/log4j. However, it
>> will not be able to keep the same
>> name as all Git repos owned by the logging project must start with
>> “logging-“.
>> 
>> So this vote is to:
>> 1. Delete the apache/logging-log4j1 repo I created last night.
>> 2. Divorce the apache/log4j repo from SVN.
>> 3. Rename apache/log4j to apache/logging-log4j1.
>> 4. Create a branch named “main” from the v1_2_17 tag.
>> 5. Make main the default branch in GitHub.
>> 
>> While all votes are welcome Infra needs consensus from the PMC on this
>> vote so the result will separate
>> binding from non-binding votes.
>> 
>> Ralph
>> 
>> PS - I’ve separated this from the previous vote thread since it was mostly
>> discussion. If you want to discuss
>> this please prefix the subject with [DISCUSS]

Re: [VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

[Gary Gregory]

-1
We just created logging-log4j1 and converted the SVN repo into it, let's
stick to that. I even made a commit ;-)
I claim it is a good thing to start with a new repo because it creates a
tiny bit of friction, for a project that is still End-of-Life after all.
Even if it is a bit of friction to bring in old stuff from the old repo,
this would provide a kind of effort/value filter.
The concurrent consensus I see on the PMC is to fix the one listed CVE on
our site plus other fixes in the style of the recent 2.x fixes.
Bringing in all of the cruft from the old repo will give the wrong
impression that we actually might be merging this or that random fix and
feature. Which I claim is not the goal here.

I feel we might need an addendum or a subsequent VOTE with a stated goal or
charter for this repo to only provide CVE fixes (see above). Projects
usually have a charter, not components I do not think, but I think we
should have one here and put it in front and center in the README.md so we
can manage expectations for people finding the repo on GitHub.

Gary

On Thu, Dec 23, 2021 at 4:35 PM Ralph Goers 
wrote:

> In https://issues.apache.org/jira/browse/INFRA-22654 Chris Lambertus has
> recommended that we can divorce
> the read-only SVN repo from https://github.com/apache/log4j. However, it
> will not be able to keep the same
> name as all Git repos owned by the logging project must start with
> “logging-“.
>
> So this vote is to:
> 1. Delete the apache/logging-log4j1 repo I created last night.
> 2. Divorce the apache/log4j repo from SVN.
> 3. Rename apache/log4j to apache/logging-log4j1.
> 4. Create a branch named “main” from the v1_2_17 tag.
> 5. Make main the default branch in GitHub.
>
> While all votes are welcome Infra needs consensus from the PMC on this
> vote so the result will separate
> binding from non-binding votes.
>
> Ralph
>
> PS - I’ve separated this from the previous vote thread since it was mostly
> discussion. If you want to discuss
> this please prefix the subject with [DISCUSS]

Re: [VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

[Ron Grabowski]

 +1
On Thursday, December 23, 2021, 04:45:14 PM EST, Matt Sicker 
 wrote:  
 
 +1
--
Matt Sicker

> On Dec 23, 2021, at 15:41, Dominik Psenner  wrote:
> 
> +1
> 
> --
> Sent from my phone. Typos are a kind gift to anyone who happens to find
> them.
> 
> On Thu, Dec 23, 2021, 22:38 Ralph Goers  wrote:
> 
>> +1
>> 
>> Ralph
>> 
>>> On Dec 23, 2021, at 2:35 PM, Ralph Goers 
>> wrote:
>>> 
>>> In https://issues.apache.org/jira/browse/INFRA-22654 Chris Lambertus
>> has recommended that we can divorce
>>> the read-only SVN repo from https://github.com/apache/log4j. However,
>> it will not be able to keep the same
>>> name as all Git repos owned by the logging project must start with
>> “logging-“.
>>> 
>>> So this vote is to:
>>> 1. Delete the apache/logging-log4j1 repo I created last night.
>>> 2. Divorce the apache/log4j repo from SVN.
>>> 3. Rename apache/log4j to apache/logging-log4j1.
>>> 4. Create a branch named “main” from the v1_2_17 tag.
>>> 5. Make main the default branch in GitHub.
>>> 
>>> While all votes are welcome Infra needs consensus from the PMC on this
>> vote so the result will separate
>>> binding from non-binding votes.
>>> 
>>> Ralph
>>> 
>>> PS - I’ve separated this from the previous vote thread since it was
>> mostly discussion. If you want to discuss
>>> this please prefix the subject with [DISCUSS]
>> 
>> 

  

Re: [VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

[Matt Sicker]

+1
--
Matt Sicker

> On Dec 23, 2021, at 15:41, Dominik Psenner  wrote:
> 
> +1
> 
> --
> Sent from my phone. Typos are a kind gift to anyone who happens to find
> them.
> 
> On Thu, Dec 23, 2021, 22:38 Ralph Goers  wrote:
> 
>> +1
>> 
>> Ralph
>> 
>>> On Dec 23, 2021, at 2:35 PM, Ralph Goers 
>> wrote:
>>> 
>>> In https://issues.apache.org/jira/browse/INFRA-22654 Chris Lambertus
>> has recommended that we can divorce
>>> the read-only SVN repo from https://github.com/apache/log4j. However,
>> it will not be able to keep the same
>>> name as all Git repos owned by the logging project must start with
>> “logging-“.
>>> 
>>> So this vote is to:
>>> 1. Delete the apache/logging-log4j1 repo I created last night.
>>> 2. Divorce the apache/log4j repo from SVN.
>>> 3. Rename apache/log4j to apache/logging-log4j1.
>>> 4. Create a branch named “main” from the v1_2_17 tag.
>>> 5. Make main the default branch in GitHub.
>>> 
>>> While all votes are welcome Infra needs consensus from the PMC on this
>> vote so the result will separate
>>> binding from non-binding votes.
>>> 
>>> Ralph
>>> 
>>> PS - I’ve separated this from the previous vote thread since it was
>> mostly discussion. If you want to discuss
>>> this please prefix the subject with [DISCUSS]
>> 
>> 

[VOTE] Release Apache Log4j Scala API version 13.0-rc1

[Matt Sicker]

This is a vote to release Log4j Scala API 13.0. This release primarily adds 
support for Scala 3.

Please download, test, and cast your votes on the log4j developers list.
[] +1, release the artifacts
[] -1, don't release because...

The vote will remain open for 72 hours (or more if required). All votes are 
welcome and we encourage everyone to test the release, but only Logging PMC 
votes are “officially” counted. As always, at least 3 +1 votes and more 
positive than negative votes are required.

Changes in this release include:

New Features
* LOG4J2-3184: Add support for Scala 3.0.

Tag:
a)  for a new copy do "git clone 
https://github.com/apache/logging-log4j-scala.git 
" and then "git checkout 
tags/v13.0-rc1”  or just "git clone -b v13.0-rc1 
https://github.com/apache/logging-log4j-scala.git 
"
b) for an existing working copy to “git pull” and then “git checkout 
tags/v13.0-rc1”

Web Site:  https://logging.staged.apache.org/log4j/log4j-scala-13.0/index.html 
.

Maven Artifacts: 
https://repository.apache.org/content/repositories/orgapachelogging-1077/ 


Distribution archives: 
https://dist.apache.org/repos/dist/dev/logging/log4j/scala/

You may download all the Maven artifacts by executing:
wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate 
https://repository.apache.org/content/repositories/orgapachelogging-1077/org/apache/logging/log4j/
 


--
Matt Sicker

Re: [VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

[Dominik Psenner]

+1

--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Thu, Dec 23, 2021, 22:38 Ralph Goers  wrote:

> +1
>
> Ralph
>
> > On Dec 23, 2021, at 2:35 PM, Ralph Goers 
> wrote:
> >
> > In https://issues.apache.org/jira/browse/INFRA-22654 Chris Lambertus
> has recommended that we can divorce
> > the read-only SVN repo from https://github.com/apache/log4j. However,
> it will not be able to keep the same
> > name as all Git repos owned by the logging project must start with
> “logging-“.
> >
> > So this vote is to:
> > 1. Delete the apache/logging-log4j1 repo I created last night.
> > 2. Divorce the apache/log4j repo from SVN.
> > 3. Rename apache/log4j to apache/logging-log4j1.
> > 4. Create a branch named “main” from the v1_2_17 tag.
> > 5. Make main the default branch in GitHub.
> >
> > While all votes are welcome Infra needs consensus from the PMC on this
> vote so the result will separate
> > binding from non-binding votes.
> >
> > Ralph
> >
> > PS - I’ve separated this from the previous vote thread since it was
> mostly discussion. If you want to discuss
> > this please prefix the subject with [DISCUSS]
>
>

Re: [VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

[Ralph Goers]

+1

Ralph

> On Dec 23, 2021, at 2:35 PM, Ralph Goers  wrote:
> 
> In https://issues.apache.org/jira/browse/INFRA-22654 Chris Lambertus has 
> recommended that we can divorce
> the read-only SVN repo from https://github.com/apache/log4j. However, it will 
> not be able to keep the same 
> name as all Git repos owned by the logging project must start with “logging-“.
> 
> So this vote is to:
> 1. Delete the apache/logging-log4j1 repo I created last night.
> 2. Divorce the apache/log4j repo from SVN.
> 3. Rename apache/log4j to apache/logging-log4j1.
> 4. Create a branch named “main” from the v1_2_17 tag.
> 5. Make main the default branch in GitHub.
> 
> While all votes are welcome Infra needs consensus from the PMC on this vote 
> so the result will separate 
> binding from non-binding votes.
> 
> Ralph
> 
> PS - I’ve separated this from the previous vote thread since it was mostly 
> discussion. If you want to discuss 
> this please prefix the subject with [DISCUSS]

Re: [VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

[Carter Kozak]

+1

-ck

> On Dec 23, 2021, at 16:35, Ralph Goers  wrote:
> 
> In https://issues.apache.org/jira/browse/INFRA-22654 Chris Lambertus has 
> recommended that we can divorce
> the read-only SVN repo from https://github.com/apache/log4j. However, it will 
> not be able to keep the same 
> name as all Git repos owned by the logging project must start with “logging-“.
> 
> So this vote is to:
> 1. Delete the apache/logging-log4j1 repo I created last night.
> 2. Divorce the apache/log4j repo from SVN.
> 3. Rename apache/log4j to apache/logging-log4j1.
> 4. Create a branch named “main” from the v1_2_17 tag.
> 5. Make main the default branch in GitHub.
> 
> While all votes are welcome Infra needs consensus from the PMC on this vote 
> so the result will separate 
> binding from non-binding votes.
> 
> Ralph
> 
> PS - I’ve separated this from the previous vote thread since it was mostly 
> discussion. If you want to discuss 
> this please prefix the subject with [DISCUSS]

[VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

[Ralph Goers]

In https://issues.apache.org/jira/browse/INFRA-22654 Chris Lambertus has 
recommended that we can divorce
the read-only SVN repo from https://github.com/apache/log4j. However, it will 
not be able to keep the same 
name as all Git repos owned by the logging project must start with “logging-“.

So this vote is to:
1. Delete the apache/logging-log4j1 repo I created last night.
2. Divorce the apache/log4j repo from SVN.
3. Rename apache/log4j to apache/logging-log4j1.
4. Create a branch named “main” from the v1_2_17 tag.
5. Make main the default branch in GitHub.

While all votes are welcome Infra needs consensus from the PMC on this vote so 
the result will separate 
binding from non-binding votes.

Ralph

PS - I’ve separated this from the previous vote thread since it was mostly 
discussion. If you want to discuss 
this please prefix the subject with [DISCUSS]

Re: Configuration element for system properties

[Volkan Yazıcı]

Judging from the PropertiesUtil, it is indeed not a typo but an
undocumented feature. I think we shouldn't have any undocumented features;
created LOG4J2-3287 .

A slightly related issue I have raised in 2019 was making constants a part
of the configuration
, rather
than accessing them by statics.

On Mon, Dec 20, 2021 at 9:18 PM Gary Gregory  wrote:

> Our page
> https://logging.apache.org/log4j/2.x/manual/configuration.html#SystemProperties
> documents log4j2.component.properties, but you talk about
> log4j2.system.properties. Is that a typo or are we missing
> documentation?
>
> Gary
>
> On Mon, Dec 20, 2021 at 3:12 PM Ralph Goers 
> wrote:
> >
> > This proposal is problematic. By the time this happens it is possible it
> is too late for some system properties to do any good.
> >
> > I implemented support for system properties already. I had a need for it
> for the Spring support. Just put the properties in log4j2.system.properties.
> >
> > PropertiesUtil populates the SystemProperties when it creates the
> Environment.
> >
> > Ralph
> >
> > > On Dec 20, 2021, at 12:18 PM, Gary Gregory 
> wrote:
> > >
> > > Hello,
> > >
> > > I'd like to propose that we add an element called SystemProperty to
> > > our configuration. This would look like our current Property element
> > > but would set a system property instead of a configuration property.
> > >
> > > My use case is, at work, our tooling generates one XML configuration
> > > file for a user's project and additional XML files for each DTAP
> > > environment. The main Log4j configuration file uses XInclude to bring
> > > in the appropriate DTAP file. Depending on the configuration of the
> > > user's project, and in light of Log4j's use of system properties,
> > > specifically, our new enableJndi* system properties, it would be nice
> > > to be able to say in DTAP XML files something like  > > key="enableJndiJms>true or whatever Property
> > > supports.
> > >
> > > Thoughts?
> > >
> > > Gary
> > >
> >
>

Re: [VOTE] Release log4net 2.0.14

[Matt Sicker]

Root keys are in https://downloads.apache.org/logging/KEYS which is in
the dist repository where you commit releases.

On Mon, Dec 20, 2021 at 2:03 AM Dominik Psenner  wrote:
>
> * old-log4net.snk.gpg has been the old key to sign binaries.
> * @Matt, where is the root logging KEYS file located?
>
> The changes in the release look good to me. +1
>
> On Mon, 20 Dec 2021 at 07:34, Davyd McColl  wrote:
>
> > Thanks Matt
> >
> > Since you've given a +1, I'll write up some sticky notes to address these
> > points in the near future.
> >
> > -d
> >
> >
> > On December 19, 2021 23:51:45 Matt Sicker  wrote:
> >
> > > +1
> > >
> > > Notes on the release:
> > > * I’ve copied your release signing key to the root logging KEYS file for
> > > easier discoverability.
> > > * The copyright year in the NOTICE file is a few years out of date at
> > this
> > > point. I’ve updated this in master, though you’ll want to update this
> > again
> > > in a couple weeks when it’s outdated again.
> > > * Some included files in the base directory of the source zip are
> > missing
> > > copyright headers or shouldn’t even be included in the tarball (e.g.,
> > the
> > > appveyor config file probably isn’t necessary)
> > >   - Not sure what old-log4net.snk.gpg is in there for, either.
> > >   - Gulp task source files missing headers
> > > * Artifact signatures and sha512 hashes look good (checked with shasum
> > > which is the Perl script version), contain appropriate LICENSE and
> > NOTICE
> > > (besides the outdated copyright year, but not a blocker), no binaries in
> > > the source zip, appropriate files in the binary zip.
> > >
> > > --
> > > Matt Sicker
> > >
> > >> On Dec 16, 2021, at 07:47, Davyd McColl  wrote:
> > >>
> > >> Hi all
> > >>
> > >> I'd like to raise a vote to release log4net 2.0.14. Changelog is up on
> > the
> > >> pre-release page at
> > >> https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.14-rc1
> > >>
> > >> I have updated staging docs and I _think_ I've done the right thing with
> > >> respect to getting binaries and source up to the dev repo at
> > >> https://dist.apache.org/repos/dist/dev/logging, but the download links
> > on
> > >> the staging docs point to the release download area, so I'm not sure if
> > I
> > >> should rather upload there so that staging documentation "works as
> > >> expected" for the vote to continue.
> > >>
> > >> Thanks Ralph for assisting me in being able to uplodate artifacts
> > myself.
> > >> Much appreciated.
> > >>
> > >> -d
> > >>
> > >> PS. This email is a duplicate of the one sent from my work email (
> > >> davyd.mcc...@codeo.co.za) which I believe has been lost somewhere
> > along the
> > >> way. Please ignore the other if it pops up.
> > >>
> > >>
> > >> --
> > >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> > >> If you say that getting the money is the most important thing
> > >> You will spend your life completely wasting your time
> > >> You will be doing things you don't like doing
> > >> In order to go on living
> > >> That is, to go on doing things you don't like doing
> > >>
> > >> Which is stupid.
> > >>
> > >> - Alan Watts
> > >> https://www.youtube.com/watch?v=-gXTZM_uPMY
> > >>
> > >> *Quidquid latine dictum sit, altum sonatur. *
> > >
> >
>
>
> --
> Dominik Psenner

Re: [VOTE][LAZY] Release Apache Logging Parent POM version 4 rc1

[Matt Sicker]

I'll add a +1 here. This vote passes with 3 +1 votes. I'll release to
Maven Central along with a rel/ tag.

On Thu, Dec 23, 2021 at 1:54 PM Matt Sicker  wrote:
>
> It should be a tag named logging-parent-4.
>
> On Thu, Dec 23, 2021 at 3:48 AM Volkan Yazıcı  wrote:
> >
> > +1
> >
> > I see that the changes are committed and the `logging-parent-4` branch has
> > been deleted.
> > I also see the `logging-parent-4` line in `pom.xml`. Shouldn't
> > this be HEAD instead?
> >
> > On Sun, Dec 19, 2021 at 11:40 PM Matt Sicker  wrote:
> >
> > > Hi all, this is a lazy vote to release the latest changes to our common
> > > parent POM. The changes in this release are all the same changes made
> > > between the Apache parent pom versions 23 to 24 <
> > > https://github.com/apache/maven-apache-parent/compare/apache-23...apache-24
> > > <
> > > https://github.com/apache/maven-apache-parent/compare/apache-23...apache-24
> > > >>.
> > >
> > > As these parent poms need to be manually updated in our individual
> > > subprojects, this release is done through lazy approval. An action with
> > > lazy approval is implicitly allowed unless a -1 vote is received, at which
> > > time, depending on the type of action, either lazy majority or lazy
> > > consensus approval must be obtained. This vote will remain open for at
> > > least 72 hours.
> > >
> > > Staged version:
> > > https://repository.apache.org/content/repositories/orgapachelogging-1072/org/apache/logging/logging-parent/4/logging-parent-4.pom
> > > <
> > > https://repository.apache.org/content/repositories/orgapachelogging-1072/org/apache/logging/logging-parent/4/logging-parent-4.pom
> > > >
> > >
> > > Git tag: logging-parent-4
> > >
> > > Check this out via:
> > > git clone g...@github.com:apache/logging-parent.git --branch
> > > logging-parent-4
> > >
> > > Signing key available in the usual location:
> > > https://downloads.apache.org/logging/KEYS <
> > > https://downloads.apache.org/logging/KEYS>
> > >
> > > --
> > > Matt Sicker
> > >
> > >

Re: Resurrecting log4j 1.x

[Ralph Goers]

Dominik,

The branch named “main” has been created from the v1_2_17 tag. I have created a 
ticket 
to have that branch made the GitHub default branch. Once that is done we can 
rename
trunk to something else or delete the branch entirely.

Ralph

> On Dec 23, 2021, at 1:21 PM, Dominik Psenner  wrote:
> 
> So far it has been discussed to patch 1.2.17. I propose to fork
> logging-log4j1 [1] and base improvements on tag v1_2_17,  de9f0ea. As far
> as I can tell, no additional work is required from Infra or Logging
> Services.
> 
> [1] https://github.com/apache/logging-log4j1
> --
> Sent from my phone. Typos are a kind gift to anyone who happens to find
> them.
> 
> On Thu, Dec 23, 2021, 20:58 Vladimir Sitnikov 
> wrote:
> 
>> Christian>if you send in patches there are people who would apply them
>> 
>> Thank you.
>> Let us see what INFRA says regarding https://github.com/apache/log4j in
>> https://issues.apache.org/jira/browse/INFRA-22654
>> 
>> Vladimir
>> 

Re: Resurrecting log4j 1.x

[Dominik Psenner]

So far it has been discussed to patch 1.2.17. I propose to fork
logging-log4j1 [1] and base improvements on tag v1_2_17,  de9f0ea. As far
as I can tell, no additional work is required from Infra or Logging
Services.

[1] https://github.com/apache/logging-log4j1
--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Thu, Dec 23, 2021, 20:58 Vladimir Sitnikov 
wrote:

> Christian>if you send in patches there are people who would apply them
>
> Thank you.
> Let us see what INFRA says regarding https://github.com/apache/log4j in
> https://issues.apache.org/jira/browse/INFRA-22654
>
> Vladimir
>

Re: Resurrecting log4j 1.x

[Vladimir Sitnikov]

Christian>if you send in patches there are people who would apply them

Thank you.
Let us see what INFRA says regarding https://github.com/apache/log4j in
https://issues.apache.org/jira/browse/INFRA-22654

Vladimir

Re: [VOTE][LAZY] Release Apache Logging Parent POM version 4 rc1

[Matt Sicker]

It should be a tag named logging-parent-4.

On Thu, Dec 23, 2021 at 3:48 AM Volkan Yazıcı  wrote:
>
> +1
>
> I see that the changes are committed and the `logging-parent-4` branch has
> been deleted.
> I also see the `logging-parent-4` line in `pom.xml`. Shouldn't
> this be HEAD instead?
>
> On Sun, Dec 19, 2021 at 11:40 PM Matt Sicker  wrote:
>
> > Hi all, this is a lazy vote to release the latest changes to our common
> > parent POM. The changes in this release are all the same changes made
> > between the Apache parent pom versions 23 to 24 <
> > https://github.com/apache/maven-apache-parent/compare/apache-23...apache-24
> > <
> > https://github.com/apache/maven-apache-parent/compare/apache-23...apache-24
> > >>.
> >
> > As these parent poms need to be manually updated in our individual
> > subprojects, this release is done through lazy approval. An action with
> > lazy approval is implicitly allowed unless a -1 vote is received, at which
> > time, depending on the type of action, either lazy majority or lazy
> > consensus approval must be obtained. This vote will remain open for at
> > least 72 hours.
> >
> > Staged version:
> > https://repository.apache.org/content/repositories/orgapachelogging-1072/org/apache/logging/logging-parent/4/logging-parent-4.pom
> > <
> > https://repository.apache.org/content/repositories/orgapachelogging-1072/org/apache/logging/logging-parent/4/logging-parent-4.pom
> > >
> >
> > Git tag: logging-parent-4
> >
> > Check this out via:
> > git clone g...@github.com:apache/logging-parent.git --branch
> > logging-parent-4
> >
> > Signing key available in the usual location:
> > https://downloads.apache.org/logging/KEYS <
> > https://downloads.apache.org/logging/KEYS>
> >
> > --
> > Matt Sicker
> >
> >

Re: Resurrecting log4j 1.x

[Christian Grobmeier]

Hello

On Thu, Dec 23, 2021, at 18:07, Vladimir Sitnikov wrote:
> Dominik> There are fixes for the flaws of log4j1 available: migrate to
> log4j2
>
> How does migration help me if I want to get 1.x fixed?
> log4j2 is a different product, created by a different team.
> Why should I migrate to log4j2 at all?

There is many reasons why we think log4j2 is better than log4j1 or forked 
products. To get the whole discussion, have a look at the mailing lists around 
2014 or something.

Different team - how does this affect the quality of a product? I remember the 
lengthy discussions about what is good and bad. I can tell that I feel that the 
original committers of log4j2 have spent many thoughts on how to improve 
things. 

Anyway, if you feel there is an urgent need to work on log4j1 then I think so 
be it. The ASF is meritocracy, when there are people around supporting code, 
this code can get released. Personally I don't see a reason to resurrect 
log4j1, but if you see a reason, go ahead.

> Dominik>Is there a concrete need for log4j1 to be patched
>
> 1. I request to get log4j 1.x patched. I can't show my code as it is under
> NDA, so you have to trust me here.

Trust with what exactly? Sorry if I missed something. 

> 2. Enrico Olivelli:
> https://lists.apache.org/thread/llgp7b9v1t081o3215o7xq4zpct1x0b4
> 3. 张铎(Duo Zhang):
> https://lists.apache.org/thread/j8dzoymo5z26sl08o3mvdf0353shcl2m
> 4. Andrew Purtell:
> https://lists.apache.org/thread/kv71f8vrqrhn6tlotqg76gz6khjs11vh

What I see here is basically the need to give better instructions on how to 
upgrade and improve the log4j1 bridge.
Why not working on that but going through the pain of an incubator again?
That said, I feel incubator is wrong, send in patches, become a committer here.

> Do you know migration to 2.x is not a drop-in replacement?
> It might require code or non-trivial configuration changes?
> For instance, if the application extends 1.x appenders, implements
> non-trivial re-configuration logic,
> then it can't upgrade to 2.x in a matter of days or weeks.

People had 7 years to do this. Any help for an upgrade from 1.x to 2.x is very 
welcome I think.

Anyway, despite I am not a big fan of resurrecting a buggy old software if you 
send in patches there are people who would apply them. If we feel there is 
community building around log4j1 we never had a problem with voting in new 
committers, pmc members etc.

You are welcome here, I am looking forward to patches and contributions to 
discuss.

Cheers
Christian

>
> Vladimir

Re: Log4J 1.x progress, pull request(s), plans

[Ralph Goers]

Leo,

I have created the main branch from the v1_2_17 tag. It looks like I will have 
to create a 
Jira for Infra to switch the default as it looks like we don’t have access to 
the GitHub 
tooling to do that.

Ralph

> On Dec 23, 2021, at 8:39 AM, Leo Simons  wrote:
> 
> On Thu, 23 Dec 2021 at 15:43, Christian Grobmeier 
> wrote:
> 
>> I didn't see the PRs though - are they still local on your box?
> 
> 
> On the wrong repo and lacking a target branch:
> 
> https://github.com/apache/log4j/pull/17
> https://github.com/apache/log4j/pull/16
> 
> From
> https://github.com/lsimons/log4j
> 
> For #17 I have it split across a couple branches in my forked repo, that
> could be their own PRs, but was waiting for feedback and a writeable repo.
> 
> I am not near a laptop now so won’t contribute code until mid next week.
> Hope someone can pick up where I left off.
> 
> Cheers!
> 
> Leo

Re: Resurrecting log4j 1.x

[Ralph Goers]

> On Dec 23, 2021, at 10:07 AM, Vladimir Sitnikov  
> wrote:
> 
> 
> Do you know migration to 2.x is not a drop-in replacement?
> It might require code or non-trivial configuration changes?
> For instance, if the application extends 1.x appenders, implements
> non-trivial re-configuration logic,
> then it can't upgrade to 2.x in a matter of days or weeks.

Do you know that for a fact?  Have you tried the support for 1.x appenders, 
etc? I can’t say it always works but I am quite sure you can’t say it never 
does.

Ralph

Re: Broken CI

[Gary Gregory]

I rarely have issues running tests from the mvn command line. Whatever we
have set up in GitHub seems quite complicated compared to most projects
I've seen. From Eclipse, sometimes tests fail, but I never researched it,
the mvm cmd line is what matters most anyway.

G

Gary

On Thu, Dec 23, 2021, 12:34 Carter Kozak  wrote:

> I haven't had a test flake locally in the last 6 months (at least), if we
> see flaky tests I'm in favor of fixing them rather than working around them.
>
> fwiw the non GitHub-actions tests work great on the release-2.x branch in
> my experience, when they aren't overwhelmed accessing build nodes anyhow.
> That said, I would prefer to get everything workin on GitHub actions as it
> seems to be the gold standard these days.
>
> > Last time I tried I couldn't get the mainline code to load in IntelliJ
> or Eclipse because of the packing changes that were in progress.
>
> I find release-2.x works nicely with IntelliJ idea when I set the
> project-level sdk to jdk8. the master branch may be another story. I have
> an INFRA ticket open to switch the default branch to reduce confusion:
> https://issues.apache.org/jira/browse/INFRA-22641
>
> -ck
>
> On Thu, Dec 23, 2021, at 12:25, Tim Perry wrote:
> > Is it worth marching those tests with @Ignore and filing a Jira for each
> > one? That does seem to set a bad precedent though.
> >
> > Last time I tried I couldn't get the mainline code to load in IntelliJ or
> > Eclipse because of the packing changes that were in progress. Did that
> get
> > fixed? If so, I might be able to carve out some time to look at a couple
> > tests if you point me in the right direction.
> >
> > Tim
> >
> > On Thu, Dec 23, 2021 at 7:24 AM Volkan Yazıcı  wrote:
> >
> > > Since, there are some tests which occasionally constantly fail, we use
> > > `-Dmaven.test.failure.ignore=true` in `verify` goal. This causes a
> build
> > > with test failures to be marked green. The 3rd party component,
> > > `scacap/action-surefire-report@v1`, is used to feed these failures
> back
> > > into GitHub Actions status with some pretty printing. But since the PR
> is
> > > opened by a user who doesn't have commit rights, the 3rd party
> component
> > > fails to mark the failures due to insufficient privileges. In
> > > `.github/workflows/main.yml`, I had introduced the `if:
> github.repository
> > > == 'apache/logging-log4j2'` line to work around this, but apparently
> it is
> > > broken again.
> > >
> > > I totally share your frustration, same here. Though sparing time to fix
> > > this is pretty difficult nowadays.
> > >
> > > I also need to confess, in those brief moments of insanity, I
> contemplate
> > > nuking all those flaky tests. This will simplify the CI magic a lot and
> > > enhance our confidence in the tests.
> > >
> > > On Tue, Dec 21, 2021 at 3:10 AM Gary Gregory 
> > > wrote:
> > >
> > > > After getting https://github.com/apache/logging-log4j2/pull/646 in
> what
> > > I
> > > > think is a good state, I have no idea if it is safe or not to merge
> > > because
> > > > the 1st build GitHub shows is red:
> > > >
> > > >
> > >
> https://github.com/apache/logging-log4j2/runs/4589771553?check_suite_focus=true
> > > >
> > > > I don't use GH actions the way we do here and I'm not sure why we
> need
> > > the
> > > > publish test result set when anyone can just look at the build logs.
> > > >
> > > > Gary
> > > >
> > >
> >
>

Re: Broken CI

[Tim Perry]

My issues were all on master. I've always been able to work on release-2.x
in IntelliJ or Eclipse without any issue.

I'll have to check out master and see if it works now. I have it on the
back burner to try to figure out an improved status logger life cycle.

On Thu, Dec 23, 2021 at 9:34 AM Carter Kozak  wrote:

> I haven't had a test flake locally in the last 6 months (at least), if we
> see flaky tests I'm in favor of fixing them rather than working around them.
>
> fwiw the non GitHub-actions tests work great on the release-2.x branch in
> my experience, when they aren't overwhelmed accessing build nodes anyhow.
> That said, I would prefer to get everything workin on GitHub actions as it
> seems to be the gold standard these days.
>
> > Last time I tried I couldn't get the mainline code to load in IntelliJ
> or Eclipse because of the packing changes that were in progress.
>
> I find release-2.x works nicely with IntelliJ idea when I set the
> project-level sdk to jdk8. the master branch may be another story. I have
> an INFRA ticket open to switch the default branch to reduce confusion:
> https://issues.apache.org/jira/browse/INFRA-22641
>
> -ck
>
> On Thu, Dec 23, 2021, at 12:25, Tim Perry wrote:
> > Is it worth marching those tests with @Ignore and filing a Jira for each
> > one? That does seem to set a bad precedent though.
> >
> > Last time I tried I couldn't get the mainline code to load in IntelliJ or
> > Eclipse because of the packing changes that were in progress. Did that
> get
> > fixed? If so, I might be able to carve out some time to look at a couple
> > tests if you point me in the right direction.
> >
> > Tim
> >
> > On Thu, Dec 23, 2021 at 7:24 AM Volkan Yazıcı  wrote:
> >
> > > Since, there are some tests which occasionally constantly fail, we use
> > > `-Dmaven.test.failure.ignore=true` in `verify` goal. This causes a
> build
> > > with test failures to be marked green. The 3rd party component,
> > > `scacap/action-surefire-report@v1`, is used to feed these failures
> back
> > > into GitHub Actions status with some pretty printing. But since the PR
> is
> > > opened by a user who doesn't have commit rights, the 3rd party
> component
> > > fails to mark the failures due to insufficient privileges. In
> > > `.github/workflows/main.yml`, I had introduced the `if:
> github.repository
> > > == 'apache/logging-log4j2'` line to work around this, but apparently
> it is
> > > broken again.
> > >
> > > I totally share your frustration, same here. Though sparing time to fix
> > > this is pretty difficult nowadays.
> > >
> > > I also need to confess, in those brief moments of insanity, I
> contemplate
> > > nuking all those flaky tests. This will simplify the CI magic a lot and
> > > enhance our confidence in the tests.
> > >
> > > On Tue, Dec 21, 2021 at 3:10 AM Gary Gregory 
> > > wrote:
> > >
> > > > After getting https://github.com/apache/logging-log4j2/pull/646 in
> what
> > > I
> > > > think is a good state, I have no idea if it is safe or not to merge
> > > because
> > > > the 1st build GitHub shows is red:
> > > >
> > > >
> > >
> https://github.com/apache/logging-log4j2/runs/4589771553?check_suite_focus=true
> > > >
> > > > I don't use GH actions the way we do here and I'm not sure why we
> need
> > > the
> > > > publish test result set when anyone can just look at the build logs.
> > > >
> > > > Gary
> > > >
> > >
> >
>

Re: Broken CI

[Carter Kozak]

I haven't had a test flake locally in the last 6 months (at least), if we see 
flaky tests I'm in favor of fixing them rather than working around them.

fwiw the non GitHub-actions tests work great on the release-2.x branch in my 
experience, when they aren't overwhelmed accessing build nodes anyhow. That 
said, I would prefer to get everything workin on GitHub actions as it seems to 
be the gold standard these days.

> Last time I tried I couldn't get the mainline code to load in IntelliJ or 
> Eclipse because of the packing changes that were in progress.

I find release-2.x works nicely with IntelliJ idea when I set the project-level 
sdk to jdk8. the master branch may be another story. I have an INFRA ticket 
open to switch the default branch to reduce confusion: 
https://issues.apache.org/jira/browse/INFRA-22641

-ck

On Thu, Dec 23, 2021, at 12:25, Tim Perry wrote:
> Is it worth marching those tests with @Ignore and filing a Jira for each
> one? That does seem to set a bad precedent though.
> 
> Last time I tried I couldn't get the mainline code to load in IntelliJ or
> Eclipse because of the packing changes that were in progress. Did that get
> fixed? If so, I might be able to carve out some time to look at a couple
> tests if you point me in the right direction.
> 
> Tim
> 
> On Thu, Dec 23, 2021 at 7:24 AM Volkan Yazıcı  wrote:
> 
> > Since, there are some tests which occasionally constantly fail, we use
> > `-Dmaven.test.failure.ignore=true` in `verify` goal. This causes a build
> > with test failures to be marked green. The 3rd party component,
> > `scacap/action-surefire-report@v1`, is used to feed these failures back
> > into GitHub Actions status with some pretty printing. But since the PR is
> > opened by a user who doesn't have commit rights, the 3rd party component
> > fails to mark the failures due to insufficient privileges. In
> > `.github/workflows/main.yml`, I had introduced the `if: github.repository
> > == 'apache/logging-log4j2'` line to work around this, but apparently it is
> > broken again.
> >
> > I totally share your frustration, same here. Though sparing time to fix
> > this is pretty difficult nowadays.
> >
> > I also need to confess, in those brief moments of insanity, I contemplate
> > nuking all those flaky tests. This will simplify the CI magic a lot and
> > enhance our confidence in the tests.
> >
> > On Tue, Dec 21, 2021 at 3:10 AM Gary Gregory 
> > wrote:
> >
> > > After getting https://github.com/apache/logging-log4j2/pull/646 in what
> > I
> > > think is a good state, I have no idea if it is safe or not to merge
> > because
> > > the 1st build GitHub shows is red:
> > >
> > >
> > https://github.com/apache/logging-log4j2/runs/4589771553?check_suite_focus=true
> > >
> > > I don't use GH actions the way we do here and I'm not sure why we need
> > the
> > > publish test result set when anyone can just look at the build logs.
> > >
> > > Gary
> > >
> >
> 

Re: Broken CI

[Gary Gregory]

I'm not talking about failing tests but about some other build silliness
that does not feel necessary, for example:
https://github.com/apache/logging-log4j2/runs/4620228443?check_suite_focus=true

Shows:


Run scacap/action-surefire-report@v1
Going to parse results form **/*-reports/TEST-*.xml
Result: 4015 tests run, 15 skipped, 0 failed.
Posting status 'completed' with conclusion 'success' to
https://github.com/apache/logging-log4j2/pull/651 (sha:
06c61ddc60b24610fda694aa54f4c1dd2e29ff07)
Error: Resource not accessible by integration

Gary


On Thu, Dec 23, 2021, 10:24 Volkan Yazıcı  wrote:

> Since, there are some tests which occasionally constantly fail, we use
> `-Dmaven.test.failure.ignore=true` in `verify` goal. This causes a build
> with test failures to be marked green. The 3rd party component,
> `scacap/action-surefire-report@v1`, is used to feed these failures back
> into GitHub Actions status with some pretty printing. But since the PR is
> opened by a user who doesn't have commit rights, the 3rd party component
> fails to mark the failures due to insufficient privileges. In
> `.github/workflows/main.yml`, I had introduced the `if: github.repository
> == 'apache/logging-log4j2'` line to work around this, but apparently it is
> broken again.
>
> I totally share your frustration, same here. Though sparing time to fix
> this is pretty difficult nowadays.
>
> I also need to confess, in those brief moments of insanity, I contemplate
> nuking all those flaky tests. This will simplify the CI magic a lot and
> enhance our confidence in the tests.
>
> On Tue, Dec 21, 2021 at 3:10 AM Gary Gregory 
> wrote:
>
> > After getting https://github.com/apache/logging-log4j2/pull/646 in what
> I
> > think is a good state, I have no idea if it is safe or not to merge
> because
> > the 1st build GitHub shows is red:
> >
> >
> https://github.com/apache/logging-log4j2/runs/4589771553?check_suite_focus=true
> >
> > I don't use GH actions the way we do here and I'm not sure why we need
> the
> > publish test result set when anyone can just look at the build logs.
> >
> > Gary
> >
>

Re: Broken CI

[Tim Perry]

Is it worth marching those tests with @Ignore and filing a Jira for each
one? That does seem to set a bad precedent though.

Last time I tried I couldn't get the mainline code to load in IntelliJ or
Eclipse because of the packing changes that were in progress. Did that get
fixed? If so, I might be able to carve out some time to look at a couple
tests if you point me in the right direction.

Tim

On Thu, Dec 23, 2021 at 7:24 AM Volkan Yazıcı  wrote:

> Since, there are some tests which occasionally constantly fail, we use
> `-Dmaven.test.failure.ignore=true` in `verify` goal. This causes a build
> with test failures to be marked green. The 3rd party component,
> `scacap/action-surefire-report@v1`, is used to feed these failures back
> into GitHub Actions status with some pretty printing. But since the PR is
> opened by a user who doesn't have commit rights, the 3rd party component
> fails to mark the failures due to insufficient privileges. In
> `.github/workflows/main.yml`, I had introduced the `if: github.repository
> == 'apache/logging-log4j2'` line to work around this, but apparently it is
> broken again.
>
> I totally share your frustration, same here. Though sparing time to fix
> this is pretty difficult nowadays.
>
> I also need to confess, in those brief moments of insanity, I contemplate
> nuking all those flaky tests. This will simplify the CI magic a lot and
> enhance our confidence in the tests.
>
> On Tue, Dec 21, 2021 at 3:10 AM Gary Gregory 
> wrote:
>
> > After getting https://github.com/apache/logging-log4j2/pull/646 in what
> I
> > think is a good state, I have no idea if it is safe or not to merge
> because
> > the 1st build GitHub shows is red:
> >
> >
> https://github.com/apache/logging-log4j2/runs/4589771553?check_suite_focus=true
> >
> > I don't use GH actions the way we do here and I'm not sure why we need
> the
> > publish test result set when anyone can just look at the build logs.
> >
> > Gary
> >
>

Re: Resurrecting log4j 1.x

[Vladimir Sitnikov]

Dominik> There are fixes for the flaws of log4j1 available: migrate to
log4j2

How does migration help me if I want to get 1.x fixed?
log4j2 is a different product, created by a different team.
Why should I migrate to log4j2 at all?

Dominik>Is there a concrete need for log4j1 to be patched

1. I request to get log4j 1.x patched. I can't show my code as it is under
NDA, so you have to trust me here.
2. Enrico Olivelli:
https://lists.apache.org/thread/llgp7b9v1t081o3215o7xq4zpct1x0b4
3. 张铎(Duo Zhang):
https://lists.apache.org/thread/j8dzoymo5z26sl08o3mvdf0353shcl2m
4. Andrew Purtell:
https://lists.apache.org/thread/kv71f8vrqrhn6tlotqg76gz6khjs11vh
and so on.

Do you know migration to 2.x is not a drop-in replacement?
It might require code or non-trivial configuration changes?
For instance, if the application extends 1.x appenders, implements
non-trivial re-configuration logic,
then it can't upgrade to 2.x in a matter of days or weeks.

Vladimir

Re: Resurrecting log4j 1.x

[Dominik Psenner]

There are fixes for the flaws of log4j1 available: migrate to log4j2.

Is there a concrete need for log4j1 to be patched and that need cannot be
satisfied by migrating to log4j2?

--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Thu, Dec 23, 2021, 16:39 Vladimir Sitnikov 
wrote:

> Volkan>To the best of
> Volkan>my knowledge, nobody has reached out to us with such a request
> except you
> Volkan>and Leo
>
> I think they just swallowed the pill that "1.x is marked EOL", and they did
> workarounds.
> a) make security team understand "the CVEs of 1.x are not that impactful
> for them"
> b) make internal forks that cut the problematic classes
> c) RedHat having their own fork
>
> However, now log4j went on the radars again,
> so I believe it is way easier (and better) to **fix** CVE than to keep
> explaining that
> "CVEs are not important in this specific case"
>
> I believe you might have access to the download stats for log4j.jar, so you
> can
> relate on the number of its usages.
>
> However, now I realize that the project itself is NOT dead as long as there
> are
> people that want to maintain it.
> It is not wise to say "log4j 1.x is dead" or "log4j 1.x is EOL" when there
> are people
> willing to maintain and release new versions.
> Note: I am not that crazy to do major refactorings in 1.x branch.
>
> So I figured out that releasing log4j 18+ ( : ) would make the lives of
> MANY MANY
> engineers and apps way easier. They would have a drop-in-replacement that
> fixes CVEs,
> improves security all over the world, and so on.
>
> Volkan>I bet it is a matter of months people will start asking for
> Volkan>other fixes once we make a 1.x release.
>
> Now we have a real issue: 1.x has LOTs of known CVEs.
> Could we refrain from theoretical discussions?
>
> Just in case, if in February you observe 10 newly created PRs,
> then it would be a nice problem to have.
>
> If all the PRs turn out to be trivial (e.g. fix NPE in a special case, or
> fix java.version parsing for Java 17),
> then you could just merge them and release 1.2.19
>
> If the review would take noticeable time, you could just say:
> "sorry, I have no time for reviewing the change, please consider creating a
> new PMC for log4j 1.x".
>
> **everybody's** time is limited. If you have no time or desire to
> maintain/support/review/release 1.x,
> then just ask the others do to that (e.g. invite new people to PMC or give
> away 1.x to another PMC).
>
> It might be there will be 10PRs, and there will be *noone* willing to
> review and nobody willing to inherit 1.x
> Then the PRs would be just abandoned.
>
> For instance, the current LOG4J2 JIRA has 809 issues. I doubt you will ever
> fix all of them :)
> So I doubt the question of "what do you do with old issues" or "what if
> there are 100500 open PRs"
> add any value.
>
> WDYT?
>
> Vladimir
>

Re: Resurrecting log4j 1.x

[Vladimir Sitnikov]

>Again: References, please, otherwise you're just making FUD.

CVE-2019-17571
CVE-2021-4104
there might be others

Once again: CVEs in 1.x are real (it exists now).
"pull requests created for 1.x" is theoretical (it does not exist now, and
it does not harm if that really happens).

Vladimir

Re: Resurrecting log4j 1.x

[Gary Gregory]

On Thu, Dec 23, 2021 at 11:14 AM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> >A, so in fact "1.x has LOTs of known CVEs." translate to one CVE.
>
> This is false.
> There are multiple CVEs.
>

Again: References, please, otherwise you're just making FUD.


> The vulnerabilities have different attack vectors and different
> consequences.
>
> Vladimir
>

Re: Resurrecting log4j 1.x

[Vladimir Sitnikov]

>A, so in fact "1.x has LOTs of known CVEs." translate to one CVE.

This is false.
There are multiple CVEs.
The vulnerabilities have different attack vectors and different
consequences.

Vladimir

Re: Resurrecting log4j 1.x

[Gary Gregory]

On Thu, Dec 23, 2021 at 11:05 AM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:
>
> >Where is this CVE tonnage?
>
> JMSAppender
> JMSSink
> chainsaw
> SocketServer
> infinite recursion (1.x does have some recursive code trying to replace
> variables)
> 
>
> I do not know CVE numbers, yet I just see the bugs are there.


A, so in fact "1.x has LOTs of known CVEs." translate to one CVE.

Thanks for the FUD.

G

>
>
> Vladimir

Re: Resurrecting log4j 1.x

[Vladimir Sitnikov]

>Where is this CVE tonnage?

JMSAppender
JMSSink
chainsaw
SocketServer
infinite recursion (1.x does have some recursive code trying to replace
variables)


I do not know CVE numbers, yet I just see the bugs are there.

Vladimir

Re: Resurrecting log4j 1.x

[Gary Gregory]

>Now we have a real issue: 1.x has LOTs of known CVEs.
>Could we refrain from theoretical discussions?

We document CVE-2019-17571/

Where is this CVE tonnage?

Gary

On Thu, Dec 23, 2021 at 10:39 AM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> Volkan>To the best of
> Volkan>my knowledge, nobody has reached out to us with such a request
> except you
> Volkan>and Leo
>
> I think they just swallowed the pill that "1.x is marked EOL", and they did
> workarounds.
> a) make security team understand "the CVEs of 1.x are not that impactful
> for them"
> b) make internal forks that cut the problematic classes
> c) RedHat having their own fork
>
> However, now log4j went on the radars again,
> so I believe it is way easier (and better) to **fix** CVE than to keep
> explaining that
> "CVEs are not important in this specific case"
>
> I believe you might have access to the download stats for log4j.jar, so you
> can
> relate on the number of its usages.
>
> However, now I realize that the project itself is NOT dead as long as there
> are
> people that want to maintain it.
> It is not wise to say "log4j 1.x is dead" or "log4j 1.x is EOL" when there
> are people
> willing to maintain and release new versions.
> Note: I am not that crazy to do major refactorings in 1.x branch.
>
> So I figured out that releasing log4j 18+ ( : ) would make the lives of
> MANY MANY
> engineers and apps way easier. They would have a drop-in-replacement that
> fixes CVEs,
> improves security all over the world, and so on.
>
> Volkan>I bet it is a matter of months people will start asking for
> Volkan>other fixes once we make a 1.x release.
>
> Now we have a real issue: 1.x has LOTs of known CVEs.
> Could we refrain from theoretical discussions?
>
> Just in case, if in February you observe 10 newly created PRs,
> then it would be a nice problem to have.
>
> If all the PRs turn out to be trivial (e.g. fix NPE in a special case, or
> fix java.version parsing for Java 17),
> then you could just merge them and release 1.2.19
>
> If the review would take noticeable time, you could just say:
> "sorry, I have no time for reviewing the change, please consider creating a
> new PMC for log4j 1.x".
>
> **everybody's** time is limited. If you have no time or desire to
> maintain/support/review/release 1.x,
> then just ask the others do to that (e.g. invite new people to PMC or give
> away 1.x to another PMC).
>
> It might be there will be 10PRs, and there will be *noone* willing to
> review and nobody willing to inherit 1.x
> Then the PRs would be just abandoned.
>
> For instance, the current LOG4J2 JIRA has 809 issues. I doubt you will ever
> fix all of them :)
> So I doubt the question of "what do you do with old issues" or "what if
> there are 100500 open PRs"
> add any value.
>
> WDYT?
>
> Vladimir
>

Re: Resurrecting log4j 1.x

[Vladimir Sitnikov]

> I think we will try to meet once or twice a month primarily to
>reduce that backlog.

If you ever figure out the solution, please tweet or blog on that (or at
least mention me).
I think ANY successful project ends up in 100500 open issues.

For instance:
https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
https://github.com/gradle/gradle/issues 1900 open, 7000 closed
...

I do not blame you. I just mention you cant fix all the issues for
everybody.
However, it is fair to accept contributions when they solve real issues.

Vladimir

Re: Resurrecting log4j 1.x

[Ralph Goers]

> On Dec 23, 2021, at 8:38 AM, Vladimir Sitnikov  
> wrote:
> 
> 
> For instance, the current LOG4J2 JIRA has 809 issues. I doubt you will ever
> fix all of them :)

Actually, in the midst of working on the CVEs we discussed this. We have found 
that Slack 
calls work really well for us so I think we will try to meet once or twice a 
month primarily to 
reduce that backlog.

Ralph

Re: Log4J 1.x progress, pull request(s), plans

[Leo Simons]

On Thu, 23 Dec 2021 at 15:43, Christian Grobmeier 
wrote:

> I didn't see the PRs though - are they still local on your box?


On the wrong repo and lacking a target branch:

https://github.com/apache/log4j/pull/17
https://github.com/apache/log4j/pull/16

From
https://github.com/lsimons/log4j

For #17 I have it split across a couple branches in my forked repo, that
could be their own PRs, but was waiting for feedback and a writeable repo.

I am not near a laptop now so won’t contribute code until mid next week.
Hope someone can pick up where I left off.

Cheers!

Leo

Re: Resurrecting log4j 1.x

[Vladimir Sitnikov]

Volkan>To the best of
Volkan>my knowledge, nobody has reached out to us with such a request
except you
Volkan>and Leo

I think they just swallowed the pill that "1.x is marked EOL", and they did
workarounds.
a) make security team understand "the CVEs of 1.x are not that impactful
for them"
b) make internal forks that cut the problematic classes
c) RedHat having their own fork

However, now log4j went on the radars again,
so I believe it is way easier (and better) to **fix** CVE than to keep
explaining that
"CVEs are not important in this specific case"

I believe you might have access to the download stats for log4j.jar, so you
can
relate on the number of its usages.

However, now I realize that the project itself is NOT dead as long as there
are
people that want to maintain it.
It is not wise to say "log4j 1.x is dead" or "log4j 1.x is EOL" when there
are people
willing to maintain and release new versions.
Note: I am not that crazy to do major refactorings in 1.x branch.

So I figured out that releasing log4j 18+ ( : ) would make the lives of
MANY MANY
engineers and apps way easier. They would have a drop-in-replacement that
fixes CVEs,
improves security all over the world, and so on.

Volkan>I bet it is a matter of months people will start asking for
Volkan>other fixes once we make a 1.x release.

Now we have a real issue: 1.x has LOTs of known CVEs.
Could we refrain from theoretical discussions?

Just in case, if in February you observe 10 newly created PRs,
then it would be a nice problem to have.

If all the PRs turn out to be trivial (e.g. fix NPE in a special case, or
fix java.version parsing for Java 17),
then you could just merge them and release 1.2.19

If the review would take noticeable time, you could just say:
"sorry, I have no time for reviewing the change, please consider creating a
new PMC for log4j 1.x".

**everybody's** time is limited. If you have no time or desire to
maintain/support/review/release 1.x,
then just ask the others do to that (e.g. invite new people to PMC or give
away 1.x to another PMC).

It might be there will be 10PRs, and there will be *noone* willing to
review and nobody willing to inherit 1.x
Then the PRs would be just abandoned.

For instance, the current LOG4J2 JIRA has 809 issues. I doubt you will ever
fix all of them :)
So I doubt the question of "what do you do with old issues" or "what if
there are 100500 open PRs"
add any value.

WDYT?

Vladimir

Re: Broken CI

[Volkan Yazıcı]

Since, there are some tests which occasionally constantly fail, we use
`-Dmaven.test.failure.ignore=true` in `verify` goal. This causes a build
with test failures to be marked green. The 3rd party component,
`scacap/action-surefire-report@v1`, is used to feed these failures back
into GitHub Actions status with some pretty printing. But since the PR is
opened by a user who doesn't have commit rights, the 3rd party component
fails to mark the failures due to insufficient privileges. In
`.github/workflows/main.yml`, I had introduced the `if: github.repository
== 'apache/logging-log4j2'` line to work around this, but apparently it is
broken again.

I totally share your frustration, same here. Though sparing time to fix
this is pretty difficult nowadays.

I also need to confess, in those brief moments of insanity, I contemplate
nuking all those flaky tests. This will simplify the CI magic a lot and
enhance our confidence in the tests.

On Tue, Dec 21, 2021 at 3:10 AM Gary Gregory  wrote:

> After getting https://github.com/apache/logging-log4j2/pull/646 in what I
> think is a good state, I have no idea if it is safe or not to merge because
> the 1st build GitHub shows is red:
>
> https://github.com/apache/logging-log4j2/runs/4589771553?check_suite_focus=true
>
> I don't use GH actions the way we do here and I'm not sure why we need the
> publish test result set when anyone can just look at the build logs.
>
> Gary
>

Re: Resurrecting log4j 1.x

[Volkan Yazıcı]

Vladimir, mind helping us to quantify this "need", please? To the best of
my knowledge, nobody has reached out to us with such a request except you
and Leo. Is it a gut feeling that is the basis of your justification or is
there an explicit demand from the community that I am missing? I also did
not see any users chiming in your voting thread. You have shared some other
Log4j 1.x forks in the wild. Are these used widely?

It would be unfair to claim that the PMC is hesitant to move forward with a
simple git setup plus some fix backports, the concern is much deeper than
this. Not to mention the extra maintenance cost it will put on the
shoulders of our limited development resources. (I know you've volunteered
for maintenance, but as you also very well know, we all will be
responsible.) I bet it is a matter of months people will start asking for
other fixes once we make a 1.x release. The uncertainty about the project
communicated will be massive and irrevertible.

On Mon, Dec 20, 2021 at 3:06 PM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> Ron,
>
> There's a need to move log4j 1.x forward, and Ralph Goers suggested
> that the way to go is to re-incubate it, see [1].
>
> Could you sponsor the project or do you want Incubator to do that? (see
> [2])
>
> [1]: https://lists.apache.org/thread/mlpb9v15r8qzpc58xnjn99r6tf9yy0p5
> [2]: https://lists.apache.org/thread/c2362g4m4m4y1n7zl444ncvhmfb9oy0m
>
> Vladimir
>

Re: New Log4j 1 repo

[Gary Gregory]

Cute :-) But... Over at Apache Commons, we just dropped all trunk branches
a long time ago. No renames, it's simpler IMO.

Gary

On Thu, Dec 23, 2021 at 9:57 AM Ralph Goers 
wrote:

> I am planning on creating a branch off the 1.2.17 tag. That branch will be
> named main.
> I will make that the default branch. Then I plan to rename trunk to a nice
> name like
> DEAD-HEAD (GRATEFUL)
>
> Ralph
>
> > On Dec 23, 2021, at 7:20 AM, Gary Gregory 
> wrote:
> >
> > A name like "version" should only be for tags. Once a version is
> released,
> > it does not make sense to have a branch by that name, but it would be OK
> to
> > have a name for a "maintenance line", as we did with "2.12.x", so here we
> > would have "1.2.x" which is lame IMO because we're ONLY EVER going to
> have
> > 1.2 releases, so it might as well stay in master/main/trunk.
> >
> > Gary
> >
> > On Thu, Dec 23, 2021 at 9:17 AM Gary Gregory 
> wrote:
> >
> >> WAIT, what? That does not make sense, it's the same bad name we ended up
> >> in with the "2.12" branch instead of "2.12.x".
> >>
> >> Gary
> >>
> >> On Thu, Dec 23, 2021 at 8:50 AM Apache 
> wrote:
> >>
> >>> I was already asked to create a branch off of 1.2.17. It will become
> the
> >>> main branch so trunk can be left alone.
> >>>
> >>> Ralph
> >>>
>  On Dec 23, 2021, at 6:41 AM, Gary Gregory 
> >>> wrote:
> 
>  If we use this repo, is everyone OK renaming "trunk" to "master" in
> >>> order
>  to match the branch name of our other repos?
> 
>  Gary
> 
> > On Thu, Dec 23, 2021 at 1:34 AM Ralph Goers <
> >>> ralph.go...@dslextreme.com>
> > wrote:
> >
> > I have cloned the read-only log4j repo to
> > https://github.com/apache/logging-log4j1.
> >
> > I have followed the build instructions and had to modify the javadoc
> > plugin to not fail on errors. Now it fails in the site plugin.
> >
> > If someone else wants to take this on I would suggest the first PR
> >>> should
> > just to the pom.xml file to get the build working as is.
> >
> > Ralph
> >
> >
> >
> >>>
> >>>
> >>>
>
>

Re: New Log4j 1 repo

[Ralph Goers]

I am planning on creating a branch off the 1.2.17 tag. That branch will be 
named main. 
I will make that the default branch. Then I plan to rename trunk to a nice name 
like
DEAD-HEAD (GRATEFUL)

Ralph

> On Dec 23, 2021, at 7:20 AM, Gary Gregory  wrote:
> 
> A name like "version" should only be for tags. Once a version is released,
> it does not make sense to have a branch by that name, but it would be OK to
> have a name for a "maintenance line", as we did with "2.12.x", so here we
> would have "1.2.x" which is lame IMO because we're ONLY EVER going to have
> 1.2 releases, so it might as well stay in master/main/trunk.
> 
> Gary
> 
> On Thu, Dec 23, 2021 at 9:17 AM Gary Gregory  wrote:
> 
>> WAIT, what? That does not make sense, it's the same bad name we ended up
>> in with the "2.12" branch instead of "2.12.x".
>> 
>> Gary
>> 
>> On Thu, Dec 23, 2021 at 8:50 AM Apache  wrote:
>> 
>>> I was already asked to create a branch off of 1.2.17. It will become the
>>> main branch so trunk can be left alone.
>>> 
>>> Ralph
>>> 
 On Dec 23, 2021, at 6:41 AM, Gary Gregory 
>>> wrote:
 
 If we use this repo, is everyone OK renaming "trunk" to "master" in
>>> order
 to match the branch name of our other repos?
 
 Gary
 
> On Thu, Dec 23, 2021 at 1:34 AM Ralph Goers <
>>> ralph.go...@dslextreme.com>
> wrote:
> 
> I have cloned the read-only log4j repo to
> https://github.com/apache/logging-log4j1.
> 
> I have followed the build instructions and had to modify the javadoc
> plugin to not fail on errors. Now it fails in the site plugin.
> 
> If someone else wants to take this on I would suggest the first PR
>>> should
> just to the pom.xml file to get the build working as is.
> 
> Ralph
> 
> 
> 
>>> 
>>> 
>>> 

Re: Log4J 1.x progress, pull request(s), plans

[Christian Grobmeier]

Hi

On Thu, Dec 23, 2021, at 14:51, Leo Simons wrote:
> Thanks for chipping in Christian! Your detailed notes from back then helped
> a ton figure basic things out.
>
> What I did for the PRs I made is to
>
> * also check in the 32 bit 1.2.17 dll from the binary release, like was
> already done for 64 bit,
> * have the maven build not auto-attempt to build it,
> * make its single unit test not even attempt to run except on windows,
> * add a matrix build that includes running on windows so that the
> windows-only test gets run frequently
> * did a little test on a windows machine with one of the DLLs
>
> Basically does for the 32 bit DLL what was already done for the 64 bit DLL.
>
> I think it’s good enough like that.
>
> Additional todo could be
> * add better INSTALL instructions for how to rebuild the dlls with ant

Definitely. It looked like a waste of time back then with 2.0 approaching.

Personally I have no access to a Windows machine. I cannot run the windows 
build part.

Apart from that, I am helping with the release of a 1.2.18, even if it hurts 
like hell

> * add another CI / GitHub action build that rebuilds the DLLs
>
> I think it is best to produce the DLLs on windows and the official release
> on linux, and to not attempt to have build orchestration to glue those
> together. It’s an exceptionally messy thing to rebuild from source without
> manual step, while the manual step is easy.

I think so. 

I didn't see the PRs though - are they still local on your box?

Kind regards,
Christian


>
> Cheers,
>
> Leo
>
>
> On Thu, 23 Dec 2021 at 14:34, Gary Gregory  wrote:
>
>> On Thu, Dec 23, 2021 at 8:20 AM Christian Grobmeier 
>> wrote:
>>
>> >
>> > On Thu, Dec 23, 2021, at 14:05, Gary Gregory wrote:
>> > > One of the difficulties was likely related to building the Windows DLLs
>> > > for
>> > > using the Windows Event Log Appender (
>> > >
>> >
>> https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/nt/NTEventLogAppender.html
>> > ).
>> > > I remember that being challenging. I can't recall if we signed the DLLs
>> > > like we might do for Apache Commons Daemons Windows binaries. Another
>> > > hurdle.
>> >
>> > Correct, the DLL is even in the codebase.
>> >
>> >
>> https://github.com/apache/logging-log4j1/blob/trunk/NTEventLogAppender.amd64.dll
>> >
>> > If we would remove that Appender, it would be much easier to build, when
>> I
>> > remember correctly.
>> > Would - in this case - an 1.2.18 with a NoOp NTEventLogAppender be OK?
>> >
>>
>> Sadly, no. We cannot break binary compatibility, that would create a bigger
>> mess: Jar hell. Some folks would argue for breaking BC but that's a no-go
>> me.
>>
>> I feel like the projects I've worked on like Apache Commons and
>> HttpComponents have benefitted *massively* from providing binary
>> compatibility. Giving users drop-in replacements is a huge help.
>>
>> Recall that Apache officially *only releases source code*, and that source
>> code must be buildable, no matter how complex the instructions. Any
>> binaries are only provided as a convenience, that includes jar files and
>> DLLs.
>>
>> Gary
>>
>>
>> > >
>> > > FWIW, my opinion has been to NOT resurrect 1.x and put our energies
>> into
>> > > improving the 1.2 bridge and configuration file support we already have
>> > in
>> > > 2.x. That said, if we decides to move forward with 1.2.18, I'll help.
>> > >
>> > > No matter what, it needs to be a decision made carefully and not in
>> > haste.
>> > >
>> >
>> > +1
>> >
>> > > Gary
>> > >
>> > > On Thu, Dec 23, 2021 at 7:56 AM Christian Grobmeier <
>> > grobme...@apache.org>
>> > > wrote:
>> > >
>> > >> Hello
>> > >>
>> > >> I have been the person cutting the 1.2.17 release and what I remember
>> > was
>> > >> it was a super hard build. I had to install some VMs because there
>> were
>> > >> weird dependencies to this build. Building it fully will not be easy,
>> > but I
>> > >> can also look into some mails whatever I found from that time.
>> > >> Here is some build info.:
>> > >> https://github.com/apache/logging-log4j1/blob/trunk/INSTALL
>> > >> Some unit tests only run with a Windows VM
>> > >>
>> > >> It would be easier to remove some components, but BC is broken then.
>> > >>
>> > >> We told people in August 2015 this is EOL. I am honestly surprised
>> that
>> > we
>> > >> discuss a new release after 7 years. To my understanding the
>> JMSAppender
>> > >> issue is not as critical (just don't configure it). If a
>> > reconfiguration of
>> > >> system is not on the cards, I wonder if upgrading from 1.2.17 to
>> 1.2.18
>> > is.
>> > >>
>> > >> That said i don't think we should resurrect it.
>> > >>
>> > >> If somebody really wants to work on, I also don't think we should go
>> > >> through the incubator. We can do this using the normal processes and
>> > apply
>> > >> patches, vote on new committers etc.
>> > >>
>> > >> My 2 cents.
>> > >>
>> > >> Christian
>> > >>
>> > >>
>> > >> On Mon, Dec 20, 2021, at 01:36, Gary Gregory wrote:
>> > 

Re: Log4J 1.x progress, pull request(s), plans

[Vladimir Sitnikov]

Gary>If you manage your Maven (for example) POM properly,
Gary>and you assemble a distribution you'll only end up with the latest
version.

Then I don't truly understand what did you mean by mentioning "Jar hell".

I claim that removal of NTEventLogAppender can't cause "jar hell"
because people either keep using 1.2.17 or upgrade to 1.2.18.

You said: "We cannot break binary compatibility, that would create a bigger
mess: Jar hell"
What I say is that if people end up with *both* 1.2.17 and 1.2.18
on the classpath (e.g. failing to manually replace jars in all the places),
they would be screwed no matter how we try keep the compatibility.
That is why removing a rarely used class is not a showstopper.

All in all, it looks like Leo has already fixed the compilation of
the native code, so the discussion of "removal NTEventLogAppender"
is not that important.

Vladimir

Re: Log4J 1.x progress, pull request(s), plans

[Gary Gregory]

On Thu, Dec 23, 2021 at 8:48 AM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> Gary,
>
> If someone manages to have **both** log4j-1.2.17.jar **and**
> log4j-1.2.18.jar
> on the same classpath, nothing can help them. Really.
> Binary compatibility can't heal that.
>

You're confusing managing a classpath manually with having a dependency
tool do it for you. If you manage your Maven (for example) POM properly,
and you assemble a distribution you'll only end up with the latest version.
Gary


> Even if 1.2.18 was fully binary compatible, adding both jars to the
> classpath
> would blow the system anyway.
>
> In other words, I suggest the following message for NTEventLogAppender
> users:
> "sorry, if you use NTEventLogAppender you might have to skip 1.2.18 version
> or replace NT appender with others"
>
> We can't make 100% of the planet happy.
> For instance, I am sure releasing 1.2.18 makes the log4j2 team greatly
> unhappy no matter what.
>
> If we weigh "spend months on trying to build, sign and test
> NTEventLogAppender" vs
> "release 1.2.18 and say sorry to NTEventLogAppender users",
> I would go for dropping NT* (at least, as a temporary solution).
>
> Vladimir
>

Re: New Log4j 1 repo

[Gary Gregory]

A name like "version" should only be for tags. Once a version is released,
it does not make sense to have a branch by that name, but it would be OK to
have a name for a "maintenance line", as we did with "2.12.x", so here we
would have "1.2.x" which is lame IMO because we're ONLY EVER going to have
1.2 releases, so it might as well stay in master/main/trunk.

Gary

On Thu, Dec 23, 2021 at 9:17 AM Gary Gregory  wrote:

> WAIT, what? That does not make sense, it's the same bad name we ended up
> in with the "2.12" branch instead of "2.12.x".
>
> Gary
>
> On Thu, Dec 23, 2021 at 8:50 AM Apache  wrote:
>
>> I was already asked to create a branch off of 1.2.17. It will become the
>> main branch so trunk can be left alone.
>>
>> Ralph
>>
>> > On Dec 23, 2021, at 6:41 AM, Gary Gregory 
>> wrote:
>> >
>> > If we use this repo, is everyone OK renaming "trunk" to "master" in
>> order
>> > to match the branch name of our other repos?
>> >
>> > Gary
>> >
>> >> On Thu, Dec 23, 2021 at 1:34 AM Ralph Goers <
>> ralph.go...@dslextreme.com>
>> >> wrote:
>> >>
>> >> I have cloned the read-only log4j repo to
>> >> https://github.com/apache/logging-log4j1.
>> >>
>> >> I have followed the build instructions and had to modify the javadoc
>> >> plugin to not fail on errors. Now it fails in the site plugin.
>> >>
>> >> If someone else wants to take this on I would suggest the first PR
>> should
>> >> just to the pom.xml file to get the build working as is.
>> >>
>> >> Ralph
>> >>
>> >>
>> >>
>>
>>
>>

Re: New Log4j 1 repo

[Gary Gregory]

WAIT, what? That does not make sense, it's the same bad name we ended up in
with the "2.12" branch instead of "2.12.x".

Gary

On Thu, Dec 23, 2021 at 8:50 AM Apache  wrote:

> I was already asked to create a branch off of 1.2.17. It will become the
> main branch so trunk can be left alone.
>
> Ralph
>
> > On Dec 23, 2021, at 6:41 AM, Gary Gregory 
> wrote:
> >
> > If we use this repo, is everyone OK renaming "trunk" to "master" in
> order
> > to match the branch name of our other repos?
> >
> > Gary
> >
> >> On Thu, Dec 23, 2021 at 1:34 AM Ralph Goers  >
> >> wrote:
> >>
> >> I have cloned the read-only log4j repo to
> >> https://github.com/apache/logging-log4j1.
> >>
> >> I have followed the build instructions and had to modify the javadoc
> >> plugin to not fail on errors. Now it fails in the site plugin.
> >>
> >> If someone else wants to take this on I would suggest the first PR
> should
> >> just to the pom.xml file to get the build working as is.
> >>
> >> Ralph
> >>
> >>
> >>
>
>
>

Re: New Log4j 1 repo

[Gary Gregory]

On Thu, Dec 23, 2021 at 8:43 AM Carter Kozak  wrote:

> I’d rather use a name like ‘main’ or ‘develop’ for inclusivity (across all
> our projects).
>

We use 'develop' and 'master' w/i the same repos at work so that would not
help my brain :-) but I am OK changing the name to something else than
'trunk' as long as we do it consistently across all Log4j repos; it would
be best to be consistent across Logging Services project repos. Otherwise,
I know I'll fat finger something ;-)

Gary


> -ck
>
> > On Dec 23, 2021, at 08:41, Gary Gregory  wrote:
> >
> > If we use this repo, is everyone OK renaming "trunk" to "master" in
> order
> > to match the branch name of our other repos?
> >
> > Gary
> >
> >> On Thu, Dec 23, 2021 at 1:34 AM Ralph Goers  >
> >> wrote:
> >>
> >> I have cloned the read-only log4j repo to
> >> https://github.com/apache/logging-log4j1.
> >>
> >> I have followed the build instructions and had to modify the javadoc
> >> plugin to not fail on errors. Now it fails in the site plugin.
> >>
> >> If someone else wants to take this on I would suggest the first PR
> should
> >> just to the pom.xml file to get the build working as is.
> >>
> >> Ralph
> >>
> >>
> >>
>
>

Re: Log4J 1.x progress, pull request(s), plans

[Apache]

Fwiw, this sounds like a god plan to me.

Ralph

> On Dec 23, 2021, at 6:51 AM, Leo Simons  wrote:
> 
> Thanks for chipping in Christian! Your detailed notes from back then helped
> a ton figure basic things out.
> 
> What I did for the PRs I made is to
> 
> * also check in the 32 bit 1.2.17 dll from the binary release, like was
> already done for 64 bit,
> * have the maven build not auto-attempt to build it,
> * make its single unit test not even attempt to run except on windows,
> * add a matrix build that includes running on windows so that the
> windows-only test gets run frequently
> * did a little test on a windows machine with one of the DLLs
> 
> Basically does for the 32 bit DLL what was already done for the 64 bit DLL.
> 
> I think it’s good enough like that.
> 
> Additional todo could be
> * add better INSTALL instructions for how to rebuild the dlls with ant
> * add another CI / GitHub action build that rebuilds the DLLs
> 
> I think it is best to produce the DLLs on windows and the official release
> on linux, and to not attempt to have build orchestration to glue those
> together. It’s an exceptionally messy thing to rebuild from source without
> manual step, while the manual step is easy.
> 
> Cheers,
> 
> Leo
> 
> 
>> On Thu, 23 Dec 2021 at 14:34, Gary Gregory  wrote:
>> 
>> On Thu, Dec 23, 2021 at 8:20 AM Christian Grobmeier 
>> wrote:
>> 
>>> 
>>> On Thu, Dec 23, 2021, at 14:05, Gary Gregory wrote:
 One of the difficulties was likely related to building the Windows DLLs
 for
 using the Windows Event Log Appender (
 
>>> 
>> https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/nt/NTEventLogAppender.html
>>> ).
 I remember that being challenging. I can't recall if we signed the DLLs
 like we might do for Apache Commons Daemons Windows binaries. Another
 hurdle.
>>> 
>>> Correct, the DLL is even in the codebase.
>>> 
>>> 
>> https://github.com/apache/logging-log4j1/blob/trunk/NTEventLogAppender.amd64.dll
>>> 
>>> If we would remove that Appender, it would be much easier to build, when
>> I
>>> remember correctly.
>>> Would - in this case - an 1.2.18 with a NoOp NTEventLogAppender be OK?
>>> 
>> 
>> Sadly, no. We cannot break binary compatibility, that would create a bigger
>> mess: Jar hell. Some folks would argue for breaking BC but that's a no-go
>> me.
>> 
>> I feel like the projects I've worked on like Apache Commons and
>> HttpComponents have benefitted *massively* from providing binary
>> compatibility. Giving users drop-in replacements is a huge help.
>> 
>> Recall that Apache officially *only releases source code*, and that source
>> code must be buildable, no matter how complex the instructions. Any
>> binaries are only provided as a convenience, that includes jar files and
>> DLLs.
>> 
>> Gary
>> 
>> 
 
 FWIW, my opinion has been to NOT resurrect 1.x and put our energies
>> into
 improving the 1.2 bridge and configuration file support we already have
>>> in
 2.x. That said, if we decides to move forward with 1.2.18, I'll help.
 
 No matter what, it needs to be a decision made carefully and not in
>>> haste.
 
>>> 
>>> +1
>>> 
 Gary
 
 On Thu, Dec 23, 2021 at 7:56 AM Christian Grobmeier <
>>> grobme...@apache.org>
 wrote:
 
> Hello
> 
> I have been the person cutting the 1.2.17 release and what I remember
>>> was
> it was a super hard build. I had to install some VMs because there
>> were
> weird dependencies to this build. Building it fully will not be easy,
>>> but I
> can also look into some mails whatever I found from that time.
> Here is some build info.:
> https://github.com/apache/logging-log4j1/blob/trunk/INSTALL
> Some unit tests only run with a Windows VM
> 
> It would be easier to remove some components, but BC is broken then.
> 
> We told people in August 2015 this is EOL. I am honestly surprised
>> that
>>> we
> discuss a new release after 7 years. To my understanding the
>> JMSAppender
> issue is not as critical (just don't configure it). If a
>>> reconfiguration of
> system is not on the cards, I wonder if upgrading from 1.2.17 to
>> 1.2.18
>>> is.
> 
> That said i don't think we should resurrect it.
> 
> If somebody really wants to work on, I also don't think we should go
> through the incubator. We can do this using the normal processes and
>>> apply
> patches, vote on new committers etc.
> 
> My 2 cents.
> 
> Christian
> 
> 
> On Mon, Dec 20, 2021, at 01:36, Gary Gregory wrote:
>> Improving legacy compatibility is what I've been pushing. I agree
>> with
>> Matt. IMO resurrecting 1.x sets a bad precedent and is a proverbial
>>> can
> of
>> worms.
>> 
>> Gary
>> 
>> On Sun, Dec 19, 2021, 17:55 Matt Sicker  wrote:
>> 
>>> The alternative is to polish the 1.x compatibility in 2.x which is
>>> both
>>> actively maintained and 

Re: New Log4j 1 repo

[Apache]

I have VMWare on my Mac with both Ubuntu and Windows 10. So I should be able to 
run a build.

Ralph

> On Dec 23, 2021, at 5:59 AM, Christian Grobmeier  wrote:
> 
> Hi,
> 
> 
> On Thu, Dec 23, 2021, at 13:33, Vladimir Sitnikov wrote:
>>> using maven toolchain feature
>> 
>> Are toolchains really needed, especially, 1.6 and 1.7?
>> I believe Java "target=1.4" + Java 1.8 would be good enough.
>> If there are javadoc "warnings or errors", we could just suppress it.
>> At the end of the day, making the build 100 times harder by requesting Java
>> 1.6
>> looks like an overkill.
>> 
>> I think there's no way to install Java 1.6 on modern macOS.
> 
> Correct. I would suggest Docker, if there is a way to install it there.
> 
> Here is some more installation instructions:
> https://github.com/apache/logging-log4j1/blob/trunk/INSTALL
> 
> For a complete build for a release, one needs to run tests using some DLLs 
> which made it very hard back then.
> 
> Christian
> 
> 
>> 
>> Vladimir
> 

Re: Log4J 1.x progress, pull request(s), plans

[Leo Simons]

Thanks for chipping in Christian! Your detailed notes from back then helped
a ton figure basic things out.

What I did for the PRs I made is to

* also check in the 32 bit 1.2.17 dll from the binary release, like was
already done for 64 bit,
* have the maven build not auto-attempt to build it,
* make its single unit test not even attempt to run except on windows,
* add a matrix build that includes running on windows so that the
windows-only test gets run frequently
* did a little test on a windows machine with one of the DLLs

Basically does for the 32 bit DLL what was already done for the 64 bit DLL.

I think it’s good enough like that.

Additional todo could be
* add better INSTALL instructions for how to rebuild the dlls with ant
* add another CI / GitHub action build that rebuilds the DLLs

I think it is best to produce the DLLs on windows and the official release
on linux, and to not attempt to have build orchestration to glue those
together. It’s an exceptionally messy thing to rebuild from source without
manual step, while the manual step is easy.

Cheers,

Leo


On Thu, 23 Dec 2021 at 14:34, Gary Gregory  wrote:

> On Thu, Dec 23, 2021 at 8:20 AM Christian Grobmeier 
> wrote:
>
> >
> > On Thu, Dec 23, 2021, at 14:05, Gary Gregory wrote:
> > > One of the difficulties was likely related to building the Windows DLLs
> > > for
> > > using the Windows Event Log Appender (
> > >
> >
> https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/nt/NTEventLogAppender.html
> > ).
> > > I remember that being challenging. I can't recall if we signed the DLLs
> > > like we might do for Apache Commons Daemons Windows binaries. Another
> > > hurdle.
> >
> > Correct, the DLL is even in the codebase.
> >
> >
> https://github.com/apache/logging-log4j1/blob/trunk/NTEventLogAppender.amd64.dll
> >
> > If we would remove that Appender, it would be much easier to build, when
> I
> > remember correctly.
> > Would - in this case - an 1.2.18 with a NoOp NTEventLogAppender be OK?
> >
>
> Sadly, no. We cannot break binary compatibility, that would create a bigger
> mess: Jar hell. Some folks would argue for breaking BC but that's a no-go
> me.
>
> I feel like the projects I've worked on like Apache Commons and
> HttpComponents have benefitted *massively* from providing binary
> compatibility. Giving users drop-in replacements is a huge help.
>
> Recall that Apache officially *only releases source code*, and that source
> code must be buildable, no matter how complex the instructions. Any
> binaries are only provided as a convenience, that includes jar files and
> DLLs.
>
> Gary
>
>
> > >
> > > FWIW, my opinion has been to NOT resurrect 1.x and put our energies
> into
> > > improving the 1.2 bridge and configuration file support we already have
> > in
> > > 2.x. That said, if we decides to move forward with 1.2.18, I'll help.
> > >
> > > No matter what, it needs to be a decision made carefully and not in
> > haste.
> > >
> >
> > +1
> >
> > > Gary
> > >
> > > On Thu, Dec 23, 2021 at 7:56 AM Christian Grobmeier <
> > grobme...@apache.org>
> > > wrote:
> > >
> > >> Hello
> > >>
> > >> I have been the person cutting the 1.2.17 release and what I remember
> > was
> > >> it was a super hard build. I had to install some VMs because there
> were
> > >> weird dependencies to this build. Building it fully will not be easy,
> > but I
> > >> can also look into some mails whatever I found from that time.
> > >> Here is some build info.:
> > >> https://github.com/apache/logging-log4j1/blob/trunk/INSTALL
> > >> Some unit tests only run with a Windows VM
> > >>
> > >> It would be easier to remove some components, but BC is broken then.
> > >>
> > >> We told people in August 2015 this is EOL. I am honestly surprised
> that
> > we
> > >> discuss a new release after 7 years. To my understanding the
> JMSAppender
> > >> issue is not as critical (just don't configure it). If a
> > reconfiguration of
> > >> system is not on the cards, I wonder if upgrading from 1.2.17 to
> 1.2.18
> > is.
> > >>
> > >> That said i don't think we should resurrect it.
> > >>
> > >> If somebody really wants to work on, I also don't think we should go
> > >> through the incubator. We can do this using the normal processes and
> > apply
> > >> patches, vote on new committers etc.
> > >>
> > >> My 2 cents.
> > >>
> > >> Christian
> > >>
> > >>
> > >> On Mon, Dec 20, 2021, at 01:36, Gary Gregory wrote:
> > >> > Improving legacy compatibility is what I've been pushing. I agree
> with
> > >> > Matt. IMO resurrecting 1.x sets a bad precedent and is a proverbial
> > can
> > >> of
> > >> > worms.
> > >> >
> > >> > Gary
> > >> >
> > >> > On Sun, Dec 19, 2021, 17:55 Matt Sicker  wrote:
> > >> >
> > >> >> The alternative is to polish the 1.x compatibility in 2.x which is
> > both
> > >> >> actively maintained and much easier to get releases published. Then
> > >> users
> > >> >> on 1.x can more easily upgrade to 2.x. I can almost guarantee that
> > >> >> regardless of how many 

Re: New Log4j 1 repo

[Apache]

I was already asked to create a branch off of 1.2.17. It will become the main 
branch so trunk can be left alone.

Ralph

> On Dec 23, 2021, at 6:41 AM, Gary Gregory  wrote:
> 
> If we use this repo, is everyone OK renaming "trunk" to "master" in order
> to match the branch name of our other repos?
> 
> Gary
> 
>> On Thu, Dec 23, 2021 at 1:34 AM Ralph Goers 
>> wrote:
>> 
>> I have cloned the read-only log4j repo to
>> https://github.com/apache/logging-log4j1.
>> 
>> I have followed the build instructions and had to modify the javadoc
>> plugin to not fail on errors. Now it fails in the site plugin.
>> 
>> If someone else wants to take this on I would suggest the first PR should
>> just to the pom.xml file to get the build working as is.
>> 
>> Ralph
>> 
>> 
>> 

Re: Log4J 1.x progress, pull request(s), plans

[Vladimir Sitnikov]

Gary,

If someone manages to have **both** log4j-1.2.17.jar **and**
log4j-1.2.18.jar
on the same classpath, nothing can help them. Really.
Binary compatibility can't heal that.

Even if 1.2.18 was fully binary compatible, adding both jars to the
classpath
would blow the system anyway.

In other words, I suggest the following message for NTEventLogAppender
users:
"sorry, if you use NTEventLogAppender you might have to skip 1.2.18 version
or replace NT appender with others"

We can't make 100% of the planet happy.
For instance, I am sure releasing 1.2.18 makes the log4j2 team greatly
unhappy no matter what.

If we weigh "spend months on trying to build, sign and test
NTEventLogAppender" vs
"release 1.2.18 and say sorry to NTEventLogAppender users",
I would go for dropping NT* (at least, as a temporary solution).

Vladimir

Re: New Log4j 1 repo

[Carter Kozak]

I’d rather use a name like ‘main’ or ‘develop’ for inclusivity (across all our 
projects).

-ck

> On Dec 23, 2021, at 08:41, Gary Gregory  wrote:
> 
> If we use this repo, is everyone OK renaming "trunk" to "master" in order
> to match the branch name of our other repos?
> 
> Gary
> 
>> On Thu, Dec 23, 2021 at 1:34 AM Ralph Goers 
>> wrote:
>> 
>> I have cloned the read-only log4j repo to
>> https://github.com/apache/logging-log4j1.
>> 
>> I have followed the build instructions and had to modify the javadoc
>> plugin to not fail on errors. Now it fails in the site plugin.
>> 
>> If someone else wants to take this on I would suggest the first PR should
>> just to the pom.xml file to get the build working as is.
>> 
>> Ralph
>> 
>> 
>> 

Re: New Log4j 1 repo

[Gary Gregory]

If we use this repo, is everyone OK renaming "trunk" to "master" in order
to match the branch name of our other repos?

Gary

On Thu, Dec 23, 2021 at 1:34 AM Ralph Goers 
wrote:

> I have cloned the read-only log4j repo to
> https://github.com/apache/logging-log4j1.
>
> I have followed the build instructions and had to modify the javadoc
> plugin to not fail on errors. Now it fails in the site plugin.
>
> If someone else wants to take this on I would suggest the first PR should
> just to the pom.xml file to get the build working as is.
>
> Ralph
>
>
>

Re: Log4J 1.x progress, pull request(s), plans

[Gary Gregory]

On Thu, Dec 23, 2021 at 8:31 AM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> >Would - in this case - an 1.2.18 with a NoOp NTEventLogAppender be OK?
>
> I am sure 1.2.18 with NoOp (or even throwing NTEventLogAppender unless a
> silence system property is set)
> appender would be more than enough for 1.2.18
>
> If the appender is not used in the wild, we are ok.
> If somebody still uses the appender, they would have an opportunity to
> mention it.
> If somebody would want to resurrect NTEventLogAppender, we could add it as
> a new "module" (==separate jar file).
>
> At any point in time, users have an option to keep using 1.2.17 that they
> used for ages.
>

In actuality, that is not the case. When you deal with large stacks,
transitive dependencies often bring in different versions of the same
artifact from completely different branches of your dependency tree,
*especially* with low-level libraries like... logging, which is why it is
critical to provide binary compatibility.

Gary


> So removing NTEventLogAppender is not really bad, and there's always an
> option to re-introduce it.
>
> Vladimir
>

Re: Log4J 1.x progress, pull request(s), plans

[Gary Gregory]

On Thu, Dec 23, 2021 at 8:20 AM Christian Grobmeier 
wrote:

>
> On Thu, Dec 23, 2021, at 14:05, Gary Gregory wrote:
> > One of the difficulties was likely related to building the Windows DLLs
> > for
> > using the Windows Event Log Appender (
> >
> https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/nt/NTEventLogAppender.html
> ).
> > I remember that being challenging. I can't recall if we signed the DLLs
> > like we might do for Apache Commons Daemons Windows binaries. Another
> > hurdle.
>
> Correct, the DLL is even in the codebase.
>
> https://github.com/apache/logging-log4j1/blob/trunk/NTEventLogAppender.amd64.dll
>
> If we would remove that Appender, it would be much easier to build, when I
> remember correctly.
> Would - in this case - an 1.2.18 with a NoOp NTEventLogAppender be OK?
>

Sadly, no. We cannot break binary compatibility, that would create a bigger
mess: Jar hell. Some folks would argue for breaking BC but that's a no-go
me.

I feel like the projects I've worked on like Apache Commons and
HttpComponents have benefitted *massively* from providing binary
compatibility. Giving users drop-in replacements is a huge help.

Recall that Apache officially *only releases source code*, and that source
code must be buildable, no matter how complex the instructions. Any
binaries are only provided as a convenience, that includes jar files and
DLLs.

Gary


> >
> > FWIW, my opinion has been to NOT resurrect 1.x and put our energies into
> > improving the 1.2 bridge and configuration file support we already have
> in
> > 2.x. That said, if we decides to move forward with 1.2.18, I'll help.
> >
> > No matter what, it needs to be a decision made carefully and not in
> haste.
> >
>
> +1
>
> > Gary
> >
> > On Thu, Dec 23, 2021 at 7:56 AM Christian Grobmeier <
> grobme...@apache.org>
> > wrote:
> >
> >> Hello
> >>
> >> I have been the person cutting the 1.2.17 release and what I remember
> was
> >> it was a super hard build. I had to install some VMs because there were
> >> weird dependencies to this build. Building it fully will not be easy,
> but I
> >> can also look into some mails whatever I found from that time.
> >> Here is some build info.:
> >> https://github.com/apache/logging-log4j1/blob/trunk/INSTALL
> >> Some unit tests only run with a Windows VM
> >>
> >> It would be easier to remove some components, but BC is broken then.
> >>
> >> We told people in August 2015 this is EOL. I am honestly surprised that
> we
> >> discuss a new release after 7 years. To my understanding the JMSAppender
> >> issue is not as critical (just don't configure it). If a
> reconfiguration of
> >> system is not on the cards, I wonder if upgrading from 1.2.17 to 1.2.18
> is.
> >>
> >> That said i don't think we should resurrect it.
> >>
> >> If somebody really wants to work on, I also don't think we should go
> >> through the incubator. We can do this using the normal processes and
> apply
> >> patches, vote on new committers etc.
> >>
> >> My 2 cents.
> >>
> >> Christian
> >>
> >>
> >> On Mon, Dec 20, 2021, at 01:36, Gary Gregory wrote:
> >> > Improving legacy compatibility is what I've been pushing. I agree with
> >> > Matt. IMO resurrecting 1.x sets a bad precedent and is a proverbial
> can
> >> of
> >> > worms.
> >> >
> >> > Gary
> >> >
> >> > On Sun, Dec 19, 2021, 17:55 Matt Sicker  wrote:
> >> >
> >> >> The alternative is to polish the 1.x compatibility in 2.x which is
> both
> >> >> actively maintained and much easier to get releases published. Then
> >> users
> >> >> on 1.x can more easily upgrade to 2.x. I can almost guarantee that
> >> >> regardless of how many warnings we add to a potential 1.x release,
> we’ll
> >> >> get inundated with CVE reports, bug reports, and email, all related
> >> solely
> >> >> to 1.x which none of us wish to maintain (especially given most of us
> >> >> weren’t even involved in 1.x back when it was in development).
> >> >> --
> >> >> Matt Sicker
> >> >>
> >> >> > On Dec 19, 2021, at 16:48, Vladimir Sitnikov <
> >> >> sitnikov.vladi...@gmail.com> wrote:
> >> >> >
> >> >> > Matt>but at least one release using the normal ASF release
> >> requirements
> >> >> is
> >> >> > required to graduate.
> >> >> >
> >> >> > Thanks for the reminder, and I am sure preparing the release won't
> be
> >> an
> >> >> > issue. I refactored release scripts for both Calcite and JMeter,
> and
> >> I am
> >> >> > sure log4j 1.x is doable.
> >> >> >
> >> >> >> compared to the alternatives discussed in this thread.
> >> >> >
> >> >> > I must be missing the alternarives.
> >> >> > Can you please highlight them?
> >> >> >
> >> >> > There were multiple suggestions and various PRs from external
> >> >> contributora,
> >> >> > yet the committers respond with vaugue messages.
> >> >> >
> >> >> > The code must be buildable, so moving to Git, and adding GitHub CI
> is
> >> the
> >> >> > mandatory step.
> >> >> > Of course, the existing PMC members and committers might have
> >> opinions on
> >> >> > the way 

Re: Log4J 1.x progress, pull request(s), plans

[Vladimir Sitnikov]

>Would - in this case - an 1.2.18 with a NoOp NTEventLogAppender be OK?

I am sure 1.2.18 with NoOp (or even throwing NTEventLogAppender unless a
silence system property is set)
appender would be more than enough for 1.2.18

If the appender is not used in the wild, we are ok.
If somebody still uses the appender, they would have an opportunity to
mention it.
If somebody would want to resurrect NTEventLogAppender, we could add it as
a new "module" (==separate jar file).

At any point in time, users have an option to keep using 1.2.17 that they
used for ages.
So removing NTEventLogAppender is not really bad, and there's always an
option to re-introduce it.

Vladimir

Re: Log4J 1.x progress, pull request(s), plans

[Christian Grobmeier]

On Thu, Dec 23, 2021, at 14:05, Gary Gregory wrote:
> One of the difficulties was likely related to building the Windows DLLs 
> for
> using the Windows Event Log Appender (
> https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/nt/NTEventLogAppender.html).
> I remember that being challenging. I can't recall if we signed the DLLs
> like we might do for Apache Commons Daemons Windows binaries. Another
> hurdle.

Correct, the DLL is even in the codebase.
https://github.com/apache/logging-log4j1/blob/trunk/NTEventLogAppender.amd64.dll

If we would remove that Appender, it would be much easier to build, when I 
remember correctly. 
Would - in this case - an 1.2.18 with a NoOp NTEventLogAppender be OK?

>
> FWIW, my opinion has been to NOT resurrect 1.x and put our energies into
> improving the 1.2 bridge and configuration file support we already have in
> 2.x. That said, if we decides to move forward with 1.2.18, I'll help.
>
> No matter what, it needs to be a decision made carefully and not in haste.
>

+1

> Gary
>
> On Thu, Dec 23, 2021 at 7:56 AM Christian Grobmeier 
> wrote:
>
>> Hello
>>
>> I have been the person cutting the 1.2.17 release and what I remember was
>> it was a super hard build. I had to install some VMs because there were
>> weird dependencies to this build. Building it fully will not be easy, but I
>> can also look into some mails whatever I found from that time.
>> Here is some build info.:
>> https://github.com/apache/logging-log4j1/blob/trunk/INSTALL
>> Some unit tests only run with a Windows VM
>>
>> It would be easier to remove some components, but BC is broken then.
>>
>> We told people in August 2015 this is EOL. I am honestly surprised that we
>> discuss a new release after 7 years. To my understanding the JMSAppender
>> issue is not as critical (just don't configure it). If a reconfiguration of
>> system is not on the cards, I wonder if upgrading from 1.2.17 to 1.2.18 is.
>>
>> That said i don't think we should resurrect it.
>>
>> If somebody really wants to work on, I also don't think we should go
>> through the incubator. We can do this using the normal processes and apply
>> patches, vote on new committers etc.
>>
>> My 2 cents.
>>
>> Christian
>>
>>
>> On Mon, Dec 20, 2021, at 01:36, Gary Gregory wrote:
>> > Improving legacy compatibility is what I've been pushing. I agree with
>> > Matt. IMO resurrecting 1.x sets a bad precedent and is a proverbial can
>> of
>> > worms.
>> >
>> > Gary
>> >
>> > On Sun, Dec 19, 2021, 17:55 Matt Sicker  wrote:
>> >
>> >> The alternative is to polish the 1.x compatibility in 2.x which is both
>> >> actively maintained and much easier to get releases published. Then
>> users
>> >> on 1.x can more easily upgrade to 2.x. I can almost guarantee that
>> >> regardless of how many warnings we add to a potential 1.x release, we’ll
>> >> get inundated with CVE reports, bug reports, and email, all related
>> solely
>> >> to 1.x which none of us wish to maintain (especially given most of us
>> >> weren’t even involved in 1.x back when it was in development).
>> >> --
>> >> Matt Sicker
>> >>
>> >> > On Dec 19, 2021, at 16:48, Vladimir Sitnikov <
>> >> sitnikov.vladi...@gmail.com> wrote:
>> >> >
>> >> > Matt>but at least one release using the normal ASF release
>> requirements
>> >> is
>> >> > required to graduate.
>> >> >
>> >> > Thanks for the reminder, and I am sure preparing the release won't be
>> an
>> >> > issue. I refactored release scripts for both Calcite and JMeter, and
>> I am
>> >> > sure log4j 1.x is doable.
>> >> >
>> >> >> compared to the alternatives discussed in this thread.
>> >> >
>> >> > I must be missing the alternarives.
>> >> > Can you please highlight them?
>> >> >
>> >> > There were multiple suggestions and various PRs from external
>> >> contributora,
>> >> > yet the committers respond with vaugue messages.
>> >> >
>> >> > The code must be buildable, so moving to Git, and adding GitHub CI is
>> the
>> >> > mandatory step.
>> >> > Of course, the existing PMC members and committers might have
>> opinions on
>> >> > the way to fix the issues, however I see no reasons for the team to
>> deny
>> >> > Git.
>> >> >
>> >> > The migration to Git consumes absolutely no resources from committers,
>> >> > except a couple of +1 votes.
>> >> >
>> >> > Unfortunately, even a trivial improvement like Git is ignored by
>> Logging
>> >> > PMC.
>> >> >
>> >> > So I take Ralph's suggestion to reestablish the new PMC for log4j 1.x
>> >> > seriously.
>> >> >
>> >> > Vladimir
>> >>
>> >>
>>

Re: New Log4j 1 repo

[Leo Simons]

Hey,

I am interested in legacy/vintage core enterprise systems deep inside large
enterprises and governments, where source code changes are out of the
question, that have lit up yellow in security/compliance dashboards due to
the old CVE against log4j 1.2 for years, that now light up as orange due to
all the increased attention to log4j.

There’s some Java 6 installs.

Rule of thumb: when I know of java 6 installs then a poor guy somewhere is
maintaining a system like that on JDK 1.4.

Practically, securing these systems is not hard. But, having dashboards go
green “the easy way” needs an official upstream (or accepted redistributor)
mitigation that is then runbooked and ideally automated.

On the PRs I made you can use -P no-toolchain to build with any modern JDK
that maven+plugins are happy with. Already proven with a working GitHub
actions maven build. What’s so hard?

Could you check if the -P no-toolchain setup works for you on Mac out of
the box? It might also be good to add a patch to switch which build is
default for convenience of the average Mac user.

Cheers,

Leo

On Thu, 23 Dec 2021 at 13:33, Vladimir Sitnikov 
wrote:

> >using maven toolchain feature
>
> Are toolchains really needed, especially, 1.6 and 1.7?
> I believe Java "target=1.4" + Java 1.8 would be good enough.
> If there are javadoc "warnings or errors", we could just suppress it.
> At the end of the day, making the build 100 times harder by requesting Java
> 1.6
> looks like an overkill.
>
> I think there's no way to install Java 1.6 on modern macOS.
>
> Vladimir
>

Re: Log4J 1.x progress, pull request(s), plans

[Gary Gregory]

One of the difficulties was likely related to building the Windows DLLs for
using the Windows Event Log Appender (
https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/nt/NTEventLogAppender.html).
I remember that being challenging. I can't recall if we signed the DLLs
like we might do for Apache Commons Daemons Windows binaries. Another
hurdle.

FWIW, my opinion has been to NOT resurrect 1.x and put our energies into
improving the 1.2 bridge and configuration file support we already have in
2.x. That said, if we decides to move forward with 1.2.18, I'll help.

No matter what, it needs to be a decision made carefully and not in haste.

Gary

On Thu, Dec 23, 2021 at 7:56 AM Christian Grobmeier 
wrote:

> Hello
>
> I have been the person cutting the 1.2.17 release and what I remember was
> it was a super hard build. I had to install some VMs because there were
> weird dependencies to this build. Building it fully will not be easy, but I
> can also look into some mails whatever I found from that time.
> Here is some build info.:
> https://github.com/apache/logging-log4j1/blob/trunk/INSTALL
> Some unit tests only run with a Windows VM
>
> It would be easier to remove some components, but BC is broken then.
>
> We told people in August 2015 this is EOL. I am honestly surprised that we
> discuss a new release after 7 years. To my understanding the JMSAppender
> issue is not as critical (just don't configure it). If a reconfiguration of
> system is not on the cards, I wonder if upgrading from 1.2.17 to 1.2.18 is.
>
> That said i don't think we should resurrect it.
>
> If somebody really wants to work on, I also don't think we should go
> through the incubator. We can do this using the normal processes and apply
> patches, vote on new committers etc.
>
> My 2 cents.
>
> Christian
>
>
> On Mon, Dec 20, 2021, at 01:36, Gary Gregory wrote:
> > Improving legacy compatibility is what I've been pushing. I agree with
> > Matt. IMO resurrecting 1.x sets a bad precedent and is a proverbial can
> of
> > worms.
> >
> > Gary
> >
> > On Sun, Dec 19, 2021, 17:55 Matt Sicker  wrote:
> >
> >> The alternative is to polish the 1.x compatibility in 2.x which is both
> >> actively maintained and much easier to get releases published. Then
> users
> >> on 1.x can more easily upgrade to 2.x. I can almost guarantee that
> >> regardless of how many warnings we add to a potential 1.x release, we’ll
> >> get inundated with CVE reports, bug reports, and email, all related
> solely
> >> to 1.x which none of us wish to maintain (especially given most of us
> >> weren’t even involved in 1.x back when it was in development).
> >> --
> >> Matt Sicker
> >>
> >> > On Dec 19, 2021, at 16:48, Vladimir Sitnikov <
> >> sitnikov.vladi...@gmail.com> wrote:
> >> >
> >> > Matt>but at least one release using the normal ASF release
> requirements
> >> is
> >> > required to graduate.
> >> >
> >> > Thanks for the reminder, and I am sure preparing the release won't be
> an
> >> > issue. I refactored release scripts for both Calcite and JMeter, and
> I am
> >> > sure log4j 1.x is doable.
> >> >
> >> >> compared to the alternatives discussed in this thread.
> >> >
> >> > I must be missing the alternarives.
> >> > Can you please highlight them?
> >> >
> >> > There were multiple suggestions and various PRs from external
> >> contributora,
> >> > yet the committers respond with vaugue messages.
> >> >
> >> > The code must be buildable, so moving to Git, and adding GitHub CI is
> the
> >> > mandatory step.
> >> > Of course, the existing PMC members and committers might have
> opinions on
> >> > the way to fix the issues, however I see no reasons for the team to
> deny
> >> > Git.
> >> >
> >> > The migration to Git consumes absolutely no resources from committers,
> >> > except a couple of +1 votes.
> >> >
> >> > Unfortunately, even a trivial improvement like Git is ignored by
> Logging
> >> > PMC.
> >> >
> >> > So I take Ralph's suggestion to reestablish the new PMC for log4j 1.x
> >> > seriously.
> >> >
> >> > Vladimir
> >>
> >>
>

Re: New Log4j 1 repo

[Christian Grobmeier]

Hi,


On Thu, Dec 23, 2021, at 13:33, Vladimir Sitnikov wrote:
>>using maven toolchain feature
>
> Are toolchains really needed, especially, 1.6 and 1.7?
> I believe Java "target=1.4" + Java 1.8 would be good enough.
> If there are javadoc "warnings or errors", we could just suppress it.
> At the end of the day, making the build 100 times harder by requesting Java
> 1.6
> looks like an overkill.
>
> I think there's no way to install Java 1.6 on modern macOS.

Correct. I would suggest Docker, if there is a way to install it there.

Here is some more installation instructions:
https://github.com/apache/logging-log4j1/blob/trunk/INSTALL

For a complete build for a release, one needs to run tests using some DLLs 
which made it very hard back then.

Christian


>
> Vladimir

Re: New Log4j 1 repo

[Gary Gregory]

Vladimir,

I appreciate your energy and your enthusiasm, I do, but you're going to
have to pick your battles IMO.

I would say we (not but really wearing my PMC hat) have passively agreed
that we can move toward fixing CVEs and potential CVEs in what would be a
1.2.18.

For us to get there and while we are still navigating this storm, means
that we all have to make compromises and make a smooth path for the team,
infra, users. This new repo is part of this smoother path. So, please don't
get caught up in the mechanics, I encourage you to look toward the finish
line.

Allow me to relate what I am seeing in the enterprise and with
organizations that provide professional services that might make this whole
thing moot. As much as I explain the differences between Log4j 1 and 2 and
the different issues that have occurred in both, the path is clear: People
finally understand what end-of-life is and are moving toward Log4j 2. Let's
skip the discussion of the Yossarian-like pickle for people who had already
migrated and stepped into the RCE CVE. As I am advising these various
people, some realize the 1.2 bridge will work fine, others have started
rewriting their configuration in Log4j 2 XML on their own. All of this to
say that, even though 1.2 might be safer within certain bounds, and made
safer in the future, stacks are just moving to 2.x.

HTH,
Gary

On Thu, Dec 23, 2021 at 7:25 AM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> >All logging services Git repos start with logging-.
>
> I'm 100% sure INFRA can rename `apache/log4j` into `apache/logging-log4j1`,
> and it would be transparent for GitHub users.
> GitHub would automatically redirect from apache/log4j to
> apache/logging-log4j1
>
> >Of course you are free to screw around
>
> Just in case you miss:
> * What I really want to do here is to heal log4j 1.x for **everybody**.
> That is why I want to get the canonical repository and the canonical Maven
> coordinates.
> * Of course, for my private applications, I have created and fixed log4j
> 1.x **long ago**.
> I just realized, this "private forks" effort is duplicated all over the
> world,
> and I realized the right thing to do is to fix the official log4j 1.x no
> matter what "Logging PMC thinks of 1.x being EOL"
>
> Vladimir
>

Re: Log4J 1.x progress, pull request(s), plans

[Christian Grobmeier]

Hello

I have been the person cutting the 1.2.17 release and what I remember was it 
was a super hard build. I had to install some VMs because there were weird 
dependencies to this build. Building it fully will not be easy, but I can also 
look into some mails whatever I found from that time. 
Here is some build info.:
https://github.com/apache/logging-log4j1/blob/trunk/INSTALL
Some unit tests only run with a Windows VM

It would be easier to remove some components, but BC is broken then.

We told people in August 2015 this is EOL. I am honestly surprised that we 
discuss a new release after 7 years. To my understanding the JMSAppender issue 
is not as critical (just don't configure it). If a reconfiguration of system is 
not on the cards, I wonder if upgrading from 1.2.17 to 1.2.18 is.

That said i don't think we should resurrect it. 

If somebody really wants to work on, I also don't think we should go through 
the incubator. We can do this using the normal processes and apply patches, 
vote on new committers etc.

My 2 cents.

Christian


On Mon, Dec 20, 2021, at 01:36, Gary Gregory wrote:
> Improving legacy compatibility is what I've been pushing. I agree with
> Matt. IMO resurrecting 1.x sets a bad precedent and is a proverbial can of
> worms.
>
> Gary
>
> On Sun, Dec 19, 2021, 17:55 Matt Sicker  wrote:
>
>> The alternative is to polish the 1.x compatibility in 2.x which is both
>> actively maintained and much easier to get releases published. Then users
>> on 1.x can more easily upgrade to 2.x. I can almost guarantee that
>> regardless of how many warnings we add to a potential 1.x release, we’ll
>> get inundated with CVE reports, bug reports, and email, all related solely
>> to 1.x which none of us wish to maintain (especially given most of us
>> weren’t even involved in 1.x back when it was in development).
>> --
>> Matt Sicker
>>
>> > On Dec 19, 2021, at 16:48, Vladimir Sitnikov <
>> sitnikov.vladi...@gmail.com> wrote:
>> >
>> > Matt>but at least one release using the normal ASF release requirements
>> is
>> > required to graduate.
>> >
>> > Thanks for the reminder, and I am sure preparing the release won't be an
>> > issue. I refactored release scripts for both Calcite and JMeter, and I am
>> > sure log4j 1.x is doable.
>> >
>> >> compared to the alternatives discussed in this thread.
>> >
>> > I must be missing the alternarives.
>> > Can you please highlight them?
>> >
>> > There were multiple suggestions and various PRs from external
>> contributora,
>> > yet the committers respond with vaugue messages.
>> >
>> > The code must be buildable, so moving to Git, and adding GitHub CI is the
>> > mandatory step.
>> > Of course, the existing PMC members and committers might have opinions on
>> > the way to fix the issues, however I see no reasons for the team to deny
>> > Git.
>> >
>> > The migration to Git consumes absolutely no resources from committers,
>> > except a couple of +1 votes.
>> >
>> > Unfortunately, even a trivial improvement like Git is ignored by Logging
>> > PMC.
>> >
>> > So I take Ralph's suggestion to reestablish the new PMC for log4j 1.x
>> > seriously.
>> >
>> > Vladimir
>>
>>

Re: New Log4j 1 repo

[Vladimir Sitnikov]

>using maven toolchain feature

Are toolchains really needed, especially, 1.6 and 1.7?
I believe Java "target=1.4" + Java 1.8 would be good enough.
If there are javadoc "warnings or errors", we could just suppress it.
At the end of the day, making the build 100 times harder by requesting Java
1.6
looks like an overkill.

I think there's no way to install Java 1.6 on modern macOS.

Vladimir

Re: New Log4j 1 repo

[Leo Simons]

Hmm my best guess still is the javadoc warning>error. I didn’t think that
started with JDK 8…

The PR I had made for trunk has this fix for it

https://github.com/apache/log4j/pull/16/commits/490255fbe6a3bc729c09be8ff36b6c965029d67c

For the 1.2.17 PR that commit is not there, probably the broken javadoc
came onto trunk after 1.2.17.

True that modern maven needs modern JDK, so setting up a compat build for
1.2.18 involved using maven toolchain feature.

Cheers,

Leo

On Thu, 23 Dec 2021 at 13:18, Apache  wrote:

> Thanks Leo. I was using Java 8 with maven 3 in a Linux VM. I don’t think
> maven 3 runs on Java 6.
>
> Ralph
>
> > On Dec 23, 2021, at 5:11 AM, Leo Simons  wrote:
> >
> > On Thu, 23 Dec 2021 at 12:39, Ralph Goers 
> > wrote:
> >
> >> It is still the middle of the night for me so I won’t do anything for
> >> several hours.
> >
> >
> > Whoa, best get some rest! :)
> >
> > I will create the branch but I am curious about the rest. When I ran the
> >> build last night it ran through a bunch of unit tests without any
> problems.
> >
> >
> > The 1.2.17 build as-is has only a short whitelist of tests being run from
> > maven. There are many more tests only set up to run with ant, without
> maven
> > invoking ant.
> >
> > I changed the maven build to run all tests. Then set up a matrix build.
> > Some of the other tests worked out of the box, not all. So then fixed the
> > tests that didn’t work with maven (or JDK 9, or Linux and JDK 11).
> Disabled
> > a couple really flaky ones.
> >
> > It then failed due to javadoc errors.
> >
> >
> > Probably you used JDK9+ where some warnings become errors. I fixed that
> too
> > in a later commit by fixing the javadoc. You can also use older JDK
> (IIRC 6
> > or 7).
> >
> > I just told the plugin not to fail and then it started executing the site
> >> plugin. I tried updating the version but that just caused it to have an
> >> error in the site.xml.
> >
> >
> > Yup, fixing the site was a lot of work!
> >
> > My question is, you said that the build has test failures. Did I not see
> >> them because of the changes after 1.2.17 or is something else going on?
> >
> >
> > I think the summary answer here is “lots is going on”!
> > 1.2.17 partially migrated the build from ant to maven 2, back in 2012.
> > Frankly it wasn’t in so clean a state at time of release.
> > That makes sense since all the plug-in stability in maven really only
> came
> > after maven 3. Back then it was pretty normal to work around plugin
> > regressions every point release…you can see TODO comments in the 1.2.17
> pom
> > about it…
> > ….you may have forgotten the extent of such pain :-). Cleaning it all up
> > was a bunch of explorative surgery!
> >
> > Cheers,
> >
> > Leo
>
>
>

Re: New Log4j 1 repo

[Vladimir Sitnikov]

>All logging services Git repos start with logging-.

I'm 100% sure INFRA can rename `apache/log4j` into `apache/logging-log4j1`,
and it would be transparent for GitHub users.
GitHub would automatically redirect from apache/log4j to
apache/logging-log4j1

>Of course you are free to screw around

Just in case you miss:
* What I really want to do here is to heal log4j 1.x for **everybody**.
That is why I want to get the canonical repository and the canonical Maven
coordinates.
* Of course, for my private applications, I have created and fixed log4j
1.x **long ago**.
I just realized, this "private forks" effort is duplicated all over the
world,
and I realized the right thing to do is to fix the official log4j 1.x no
matter what "Logging PMC thinks of 1.x being EOL"

Vladimir

Re: New Log4j 1 repo

[Apache]

Thanks Leo. I was using Java 8 with maven 3 in a Linux VM. I don’t think maven 
3 runs on Java 6.

Ralph

> On Dec 23, 2021, at 5:11 AM, Leo Simons  wrote:
> 
> On Thu, 23 Dec 2021 at 12:39, Ralph Goers 
> wrote:
> 
>> It is still the middle of the night for me so I won’t do anything for
>> several hours.
> 
> 
> Whoa, best get some rest! :)
> 
> I will create the branch but I am curious about the rest. When I ran the
>> build last night it ran through a bunch of unit tests without any problems.
> 
> 
> The 1.2.17 build as-is has only a short whitelist of tests being run from
> maven. There are many more tests only set up to run with ant, without maven
> invoking ant.
> 
> I changed the maven build to run all tests. Then set up a matrix build.
> Some of the other tests worked out of the box, not all. So then fixed the
> tests that didn’t work with maven (or JDK 9, or Linux and JDK 11). Disabled
> a couple really flaky ones.
> 
> It then failed due to javadoc errors.
> 
> 
> Probably you used JDK9+ where some warnings become errors. I fixed that too
> in a later commit by fixing the javadoc. You can also use older JDK (IIRC 6
> or 7).
> 
> I just told the plugin not to fail and then it started executing the site
>> plugin. I tried updating the version but that just caused it to have an
>> error in the site.xml.
> 
> 
> Yup, fixing the site was a lot of work!
> 
> My question is, you said that the build has test failures. Did I not see
>> them because of the changes after 1.2.17 or is something else going on?
> 
> 
> I think the summary answer here is “lots is going on”!
> 1.2.17 partially migrated the build from ant to maven 2, back in 2012.
> Frankly it wasn’t in so clean a state at time of release.
> That makes sense since all the plug-in stability in maven really only came
> after maven 3. Back then it was pretty normal to work around plugin
> regressions every point release…you can see TODO comments in the 1.2.17 pom
> about it…
> ….you may have forgotten the extent of such pain :-). Cleaning it all up
> was a bunch of explorative surgery!
> 
> Cheers,
> 
> Leo

Re: New Log4j 1 repo

[Apache]

From what I can tell that repo could only be “owned” by a TLP named 
log4j.apache.org. It doesn’t show up on the list of gitbox repos owned by any 
ASF projects. I believe it is a read-only mirror tied to the sun repo. I asked 
infra about it in slack and they weren’t quite sure what it is. So rather than 
hunt that down and make everyone wait I created the new repo. All logging 
services Git repos start with logging-.

Of course you are free to screw around and try to make something happen with 
the old repo rather than just getting started.

Ralph

> On Dec 23, 2021, at 4:56 AM, Vladimir Sitnikov  
> wrote:
> 
> Leo>Instead of or in addition to some of those fixes
> 
> I would suggest the following (in case you wonder, I might volunteer to do
> ALL of that, so don't assume I just sit and tell others how things should
> be done):
> 1. Use the existing repo https://github.com/apache/log4j instead of a newly
> created one.
> The existing repo is well-known in the community (108 watch, 537 forks, 849
> stars), and it is very strange to drop all that.
> 2. Add GitHub CI so the code at least compiles. I think we should not fix
> everything like javadoc/site/whatever if it takes too much time.
> Having any CI would be way better than nothing.
> 3. Consider existing known CVE fixes (e.g. somewhere there was a mention of
> RedHat fixes for log4j 1.x CVEs).
> It might be easier to apply the fixes before the code is split.
> 4. Consider splitting the code into modules. In practice, there's already a
> branch that does exactly that:
> https://github.com/apache/log4j/tree/log4j12modules/modules
> 5. Release 1.2.18.
> 6. Treat CVEs. For instance, implement hardening in log4j-net or whatever.
> 7. Release 1.2.19
> 8 see what happens, maybe new PR would appear.
> 
> Vladimir

Re: New Log4j 1 repo

[Leo Simons]

On Thu, 23 Dec 2021 at 12:39, Ralph Goers 
wrote:

> It is still the middle of the night for me so I won’t do anything for
> several hours.


Whoa, best get some rest! :)

I will create the branch but I am curious about the rest. When I ran the
> build last night it ran through a bunch of unit tests without any problems.


The 1.2.17 build as-is has only a short whitelist of tests being run from
maven. There are many more tests only set up to run with ant, without maven
invoking ant.

I changed the maven build to run all tests. Then set up a matrix build.
Some of the other tests worked out of the box, not all. So then fixed the
tests that didn’t work with maven (or JDK 9, or Linux and JDK 11). Disabled
a couple really flaky ones.

It then failed due to javadoc errors.


Probably you used JDK9+ where some warnings become errors. I fixed that too
in a later commit by fixing the javadoc. You can also use older JDK (IIRC 6
or 7).

I just told the plugin not to fail and then it started executing the site
> plugin. I tried updating the version but that just caused it to have an
> error in the site.xml.


Yup, fixing the site was a lot of work!

My question is, you said that the build has test failures. Did I not see
> them because of the changes after 1.2.17 or is something else going on?


I think the summary answer here is “lots is going on”!
1.2.17 partially migrated the build from ant to maven 2, back in 2012.
Frankly it wasn’t in so clean a state at time of release.
That makes sense since all the plug-in stability in maven really only came
after maven 3. Back then it was pretty normal to work around plugin
regressions every point release…you can see TODO comments in the 1.2.17 pom
about it…
….you may have forgotten the extent of such pain :-). Cleaning it all up
was a bunch of explorative surgery!

Cheers,

Leo

Re: New Log4j 1 repo

[Gary Gregory]

Well done Ralph, I'll take a look today.

Gary

On Thu, Dec 23, 2021, 01:34 Ralph Goers  wrote:

> I have cloned the read-only log4j repo to
> https://github.com/apache/logging-log4j1.
>
> I have followed the build instructions and had to modify the javadoc
> plugin to not fail on errors. Now it fails in the site plugin.
>
> If someone else wants to take this on I would suggest the first PR should
> just to the pom.xml file to get the build working as is.
>
> Ralph
>
>
>

Re: New Log4j 1 repo

[Vladimir Sitnikov]

Leo>Instead of or in addition to some of those fixes

I would suggest the following (in case you wonder, I might volunteer to do
ALL of that, so don't assume I just sit and tell others how things should
be done):
1. Use the existing repo https://github.com/apache/log4j instead of a newly
created one.
The existing repo is well-known in the community (108 watch, 537 forks, 849
stars), and it is very strange to drop all that.
2. Add GitHub CI so the code at least compiles. I think we should not fix
everything like javadoc/site/whatever if it takes too much time.
Having any CI would be way better than nothing.
3. Consider existing known CVE fixes (e.g. somewhere there was a mention of
RedHat fixes for log4j 1.x CVEs).
It might be easier to apply the fixes before the code is split.
4. Consider splitting the code into modules. In practice, there's already a
branch that does exactly that:
https://github.com/apache/log4j/tree/log4j12modules/modules
5. Release 1.2.18.
6. Treat CVEs. For instance, implement hardening in log4j-net or whatever.
7. Release 1.2.19
8 see what happens, maybe new PR would appear.

Vladimir

Re: New Log4j 1 repo

[Ralph Goers]

Leo,

It is still the middle of the night for me so I won’t do anything for several 
hours. I will create the branch but I am curious about the rest. When I ran the 
build last night it ran through a bunch of unit tests without any problems. It 
then failed due to javadoc errors. I just told the plugin not to fail and then 
it started executing the site plugin. I tried updating the version but that 
just caused it to have an error in the site.xml. 

My question is, you said that the build has test failures. Did I not see them 
because of the changes after 1.2.17 or is something else going on?

Ralph

> On Dec 23, 2021, at 2:22 AM, Leo Simons  wrote:
> 
> (On mobile)
> 
> Cool.
> 
> First I suggest to make a new branch from 1.2.17. Trunk has various stuff
> that’s backwards incompatible. Something like
> 
> git checkout -b main v1_0_2_17
> git push -u main
> 
> Then go into GitHub settings and make main the default branch.
> 
> So then people make PRs against that.
> 
> Think someone can take up to  a5405370d844fca078c25f66654f929d07b1a922  from
> 
> https://github.com/apache/log4j/pull/17 to make a PR to get to a modern
> build.
> 
> With some test failures because I got rid of the limited whitelist of unit
> tests. Most of the commits after that set up GitHub actions and fix the
> test suite.
> 
> I expect you can safely take everything on that PR17 that is a commit that
> does not start with “fix:” without much discussion.
> 
> Each of those “fix:” commits from PR17 should then be a distinct PR and a
> discussion, where based on Gary’s feedback most of them have a -1 against
> them due to dropping functionality.
> 
> Instead of or in addition to some of those fixes, a nice alternative
> approach that Vladimir suggested before is to split off the more
> problematic integrations (jdbc,jms,smtp,telnet,plaintext socket) into their
> own mini library jars. Then you can replace log4j-1.2.17.jar with
> log4j-1.2.18.jar and in the rare(r) cases you do need the other stuff you
> add in, say, log4j-jms-1.2.18.jar. Easy to understand, not too much effort.
> 
> The third approach, the one Gary suggested, is to backport (the idea of)
> more secure code from 2.x.
> 
> Cheers,
> 
> Leo
> 
>> On Thu, 23 Dec 2021 at 07:34, Ralph Goers 
>> wrote:
>> 
>> I have cloned the read-only log4j repo to
>> https://github.com/apache/logging-log4j1.
>> 
>> I have followed the build instructions and had to modify the javadoc
>> plugin to not fail on errors. Now it fails in the site plugin.
>> 
>> If someone else wants to take this on I would suggest the first PR should
>> just to the pom.xml file to get the build working as is.
>> 
>> Ralph
>> 
>> 
>> 

Re: SocketAppenderReconnectTest still flaky on mac 11.8.1; raising timeout to 15 sec helps

[Volkan Yazıcı]

Thanks for the feedback. Incorporated some changes to both `master` and
`release-2.x`.

On Mon, Dec 20, 2021 at 7:49 PM Dan Kegel  wrote:

> My build procedure for the release-2.x branch succeeded on mac
> 10.16.7, but is failing one lousy test on mac 11.8.1:
>
>
> SocketAppenderReconnectTest.reconnect_should_fallback_when_there_are_multiple_resolved_hosts:129->verifyLoggingSuccess:192->awaitUntilSucceeds:219
> » ConditionTimeout
>
> I think
> https://github.com/apache/logging-log4j2/commit/b3e8818a111d884d1fbfe
> wasn't sufficient.
> Going with the same timeout as on windows seemed to work, i.e.
>
> ---
> a/log4j-core/src/test/java/org/apache/logging/log4j/core/net/SocketAppenderReconnectTest.java
> +++
> b/log4j-core/src/test/java/org/apache/logging/log4j/core/net/SocketAppenderReconnectTest.java
> @@ -211,7 +211,7 @@ class SocketAppenderReconnectTest {
>  } else {
>  // Universally sensible values.
>  pollIntervalMillis = 1000;
> -timeoutSeconds = 3;
> +timeoutSeconds = 15;
>  }
>  await()
>  .pollInterval(pollIntervalMillis, TimeUnit.MILLISECONDS)
>
> There's something about even nice fast corporate hex-core i7 macbooks
> that is slow these days, I dunno.
> - Dan
>

Re: Zero-copy rolling files

[Volkan Yazıcı]

*[I am Log4j rollover illiterate, hence apologies in advance if I am saying
something stupid.]*

Why don't we simply rename files and create new ones?
That is, `mv applog.txt applog-2021.txt` and `touch applog.txt`?
I use this in my RotatingFileOutputStream
 and there are plenty of happy
customers, even on Windows.

On Sat, Dec 18, 2021 at 4:07 PM Gary Gregory  wrote:

> Hi All:
>
> And now for something completely different.
>
> I wonder why we do not do file rollovers like below, and if we should:
> - Create the file with the target rolled over a name like applog-2021.txt
> - Create a symlink for the constant name like applog.txt to point to
> applog-2021.txt
> - When it's rollover time, start writing to the new file
> applog-2022.txt and change the symlink to point to it.
>
> Zero copy.
>
> Thoughts?
>
> Gary
>

Re: [VOTE][LAZY] Release Apache Logging Parent POM version 4 rc1

[Volkan Yazıcı]

+1

I see that the changes are committed and the `logging-parent-4` branch has
been deleted.
I also see the `logging-parent-4` line in `pom.xml`. Shouldn't
this be HEAD instead?

On Sun, Dec 19, 2021 at 11:40 PM Matt Sicker  wrote:

> Hi all, this is a lazy vote to release the latest changes to our common
> parent POM. The changes in this release are all the same changes made
> between the Apache parent pom versions 23 to 24 <
> https://github.com/apache/maven-apache-parent/compare/apache-23...apache-24
> <
> https://github.com/apache/maven-apache-parent/compare/apache-23...apache-24
> >>.
>
> As these parent poms need to be manually updated in our individual
> subprojects, this release is done through lazy approval. An action with
> lazy approval is implicitly allowed unless a -1 vote is received, at which
> time, depending on the type of action, either lazy majority or lazy
> consensus approval must be obtained. This vote will remain open for at
> least 72 hours.
>
> Staged version:
> https://repository.apache.org/content/repositories/orgapachelogging-1072/org/apache/logging/logging-parent/4/logging-parent-4.pom
> <
> https://repository.apache.org/content/repositories/orgapachelogging-1072/org/apache/logging/logging-parent/4/logging-parent-4.pom
> >
>
> Git tag: logging-parent-4
>
> Check this out via:
> git clone g...@github.com:apache/logging-parent.git --branch
> logging-parent-4
>
> Signing key available in the usual location:
> https://downloads.apache.org/logging/KEYS <
> https://downloads.apache.org/logging/KEYS>
>
> --
> Matt Sicker
>
>

Re: LOG4J2-3243

[Volkan Yazıcı]

Thanks for the clarification. I will try to enumerate all the cases below:

*[Below, 1, 2, and B denote Log4j 1, Log4j 2, and log4j-1.2-api,
respectively.]*

*1/2/B:* failure, both 1 and B cannot be present (equivalent to #1 in your
enumeration)
*1/2/-:* 2 should detect `log4j.configuration`, yet due to the absence of
B, discard it; a warning is not necessary since 1 is present (equivalent to
#2 in your enumeration)
*1/-/B:* 1 should do all the work
*1/-/-:* 1 should do all the work
*-/2/B:* 2 should detect `log4j.configuration` and employ it (equivalent to
#3 in your enumeration)
*-/2/-:* 2 should detect `log4j.configuration`, yet due to the absence of
B, warn & discard it (equivalent to #4 in your enumeration)
*-/-/B:* user doesn't know what he/she is doing
*-/-/-:* recess for all

I think we can test against all these cases using dedicated
maven-surefire-plugin configurations where we exclude either 1, 2, and/or B
as needed.

Regarding Carter's *"when interesting plugin/webapp classloaders are used"*
remark... I will act like I haven't read that. 

On Wed, Dec 22, 2021 at 6:13 PM Ralph Goers 
wrote:

>
>
> > On Dec 22, 2021, at 9:20 AM, Volkan Yazıcı  wrote:
> >
> > Ralph, mind elaborating a bit more on what the exact problem is, please?
> > `log4j.configuration` gets detected, log4j-1.2-api (provided by Log4j 2)
> > kicks in, and tries to load the Log4j 1 configuration. This sounds okay
> to
> > me. I guess it gets messed up when an application uses both Log4j 1 and
> 2,
> > right?
>
>
> Yes, if log4j 1.x is on the classpath they both think the system property
> is meant for them. There are a few scenarios:
> 1. Log4j 1.x and log4j-1.2-api are both present. This is an error as you
> can’t have both the legacy implementation and the compatibility bridge
> present at the same time.
> 2. Log4j-1.x is present and log4j-1.2-api is not present. Log4j will look
> for a factory for Log4j 1.x. It won’t find one and Log4j 2 will fail to
> configure.
> 3. Log4j 1.x is not present and log4j-1.2-api is present. Log4j will look
> for a factory for Log4j 1.x and find it in log4j-1.2-api.
> 4. Neither Log4j 1.x or Log4j-1.2-api are present. ConfigurationFactory
> won’t find a factory and will return null.
>
> It seems the logic here needs to be changed so that if it can’t find a
> Log4j 1.x configuration that it should continue looking for a Log4j 2
> configuration.  I guess having it use the Log4j 1.x property name isn’t the
> problem.
>
> Ralph

Re: New Log4j 1 repo

[Leo Simons]

(On mobile)

Cool.

First I suggest to make a new branch from 1.2.17. Trunk has various stuff
that’s backwards incompatible. Something like

git checkout -b main v1_0_2_17
git push -u main

Then go into GitHub settings and make main the default branch.

So then people make PRs against that.

Think someone can take up to  a5405370d844fca078c25f66654f929d07b1a922  from

https://github.com/apache/log4j/pull/17 to make a PR to get to a modern
build.

With some test failures because I got rid of the limited whitelist of unit
tests. Most of the commits after that set up GitHub actions and fix the
test suite.

I expect you can safely take everything on that PR17 that is a commit that
does not start with “fix:” without much discussion.

Each of those “fix:” commits from PR17 should then be a distinct PR and a
discussion, where based on Gary’s feedback most of them have a -1 against
them due to dropping functionality.

Instead of or in addition to some of those fixes, a nice alternative
approach that Vladimir suggested before is to split off the more
problematic integrations (jdbc,jms,smtp,telnet,plaintext socket) into their
own mini library jars. Then you can replace log4j-1.2.17.jar with
log4j-1.2.18.jar and in the rare(r) cases you do need the other stuff you
add in, say, log4j-jms-1.2.18.jar. Easy to understand, not too much effort.

The third approach, the one Gary suggested, is to backport (the idea of)
more secure code from 2.x.

Cheers,

Leo

On Thu, 23 Dec 2021 at 07:34, Ralph Goers 
wrote:

> I have cloned the read-only log4j repo to
> https://github.com/apache/logging-log4j1.
>
> I have followed the build instructions and had to modify the javadoc
> plugin to not fail on errors. Now it fails in the site plugin.
>
> If someone else wants to take this on I would suggest the first PR should
> just to the pom.xml file to get the build working as is.
>
> Ralph
>
>
>