Re: Looking for a champion: resurrect log4j 1.x

[Romain Manni-Bucau]

I know Vladimir but let's do things in order, if we move in all ways it
will fail.
Incubating log4j1 will fail as I epxlained - not even sure incubator would
let it be incubated since project is official dead for everybody and can
only get security fixes (incubator is to ensure you can build a community
and comply to ASF, for log4j1 it is out of topic).
If current logging PMC does not want to release they will have the choice
to donate the group for an external project or let the release be done. For
that last point you need at least 3 PMC voting and if current one does not
want to do it they can always add new PMC member willing to release -
plenty are easily found, even just in this thread.

So please stick to the normal plan:

1. do the work
2. share it properly (one feature per patch/ticket, not all at once is what
I mean here ;))
3. solve the "how to release"

To be honest speaking of 3 without having 1 and 2 is pointless.

Just to push what I just said: we had the same in maven (surefire) and the
release had been done finally so back to keyboard if anyone wants it to
happen IMHO, no need to look for future issues before they are actually
actual.

Romain

Le mer. 22 déc. 2021 à 08:42, Vladimir Sitnikov 
a écrit :

> Romain,
>
> Romain>for now the thread is looking for options which are not needed from
> my window
>
> It was the Logging PMC team who suggested I should re-incubate log4j 1.x.
>
> Romain>1. where is the patch needed to fix the desired CVE? - must be
> compatible
> with current SVN trunk
>
> The current SVN trunk is NOT buildable.
> It uses outdated build tools, so build system healing
> is needed before ANY other patches.
>
> Romain>2. please attach it to a ticket
>
> I have just created https://issues.apache.org/jira/browse/LOG4J2-3272
> "Enable Git and GitHub for log4j 1.2 repository"
>
> Every patch to 1.x must be well-tested, so attaching patch files to JIRA
> is a recipe for disaster.
>
> I already asked Logging PMC to enable Git and GitHub for 1.x, and they
> rejected it:
> https://lists.apache.org/thread/ssbdg44gy7txzl16xxd097t7orco52g2
>
> I do not see why filing the same thing as JIRA would work any better than
> sending mail to dev@logging list.
>
> Vladimir
>

Re: Looking for a champion: resurrect log4j 1.x

[Vladimir Sitnikov]

>I would propose to talk with logging PMC first

I did exactly that, and they did not listen. They have no will to keep
releasing 1.x versions.
At the same time, they do not allow others to release log4j:log4j:1.x
versions.

I'm waiting for the response by Logging PMC chair Ron once again:
https://lists.apache.org/thread/sgpc57tsl6wlklz8z682jmv4zf0l70vz

Vladimir

Re: Looking for a champion: resurrect log4j 1.x

[Vladimir Sitnikov]

Romain,

Romain>for now the thread is looking for options which are not needed from
my window

It was the Logging PMC team who suggested I should re-incubate log4j 1.x.

Romain>1. where is the patch needed to fix the desired CVE? - must be
compatible
with current SVN trunk

The current SVN trunk is NOT buildable.
It uses outdated build tools, so build system healing
is needed before ANY other patches.

Romain>2. please attach it to a ticket

I have just created https://issues.apache.org/jira/browse/LOG4J2-3272
"Enable Git and GitHub for log4j 1.2 repository"

Every patch to 1.x must be well-tested, so attaching patch files to JIRA
is a recipe for disaster.

I already asked Logging PMC to enable Git and GitHub for 1.x, and they
rejected it:
https://lists.apache.org/thread/ssbdg44gy7txzl16xxd097t7orco52g2

I do not see why filing the same thing as JIRA would work any better than
sending mail to dev@logging list.

Vladimir

Re: Looking for a champion: resurrect log4j 1.x

[JB Onofré]

Agree with Romain. Let’s just take concrete actions: I would propose to talk 
with logging PMC first (they can provide their preferences). 

It’s really amazing how we can create endless thread for simple/concrete topics 
;)

Regards 
JB

> Le 22 déc. 2021 à 08:17, Romain Manni-Bucau  a écrit :
> 
> ok, so let's try to not create an endless thread:
> 
> 1. where is the patch needed to fix the desired CVE? - must be compatible
> with current svn trunk
> 2. please attach it to a ticket (or multiple if there are multiple fixes)
> like LOG4J2-3219
> 3. if it does not get applied and PMC is opposed to get it applied let's
> create a thread about it as being an issue and look for options but for now
> the thread is looking for options which are not needed from my window
> 
> Hope it helps ot move the ball forward
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | Book
> 
> 
> 
> Le mer. 22 déc. 2021 à 06:24, Vladimir Sitnikov 
> a écrit :
> 
>> Matt>Nobody in the Logging PMC is blocking a release here.
>> 
>> Matt, thanks for the reply, however, it is false :(
>> I see you are positive, however, many more replies were quite negative.
>> 
>> Ralph Goers says: "We’ve stated several times that we don’t think
>> resurrecting Log4j 1.x permanently is a good idea."
>> https://lists.apache.org/thread/vz80p3v78xgposon3pcxbnb9729snnxt
>> 
>> Gary Gregory says: "As I've stated before, IF there is a 1.2.18, it should
>> ONLY be for CVEs,"
>> https://lists.apache.org/thread/53h130p0kdkspn4kj2hq39vkgpyzgvp7
>> 
>> They both are on Logging PMC, and they both have negative opinions on
>> making progress with v1.
>> I do not really understand what "ONLY be for CVEs" means (e.g. does it
>> allow upgrading from Maven2 to Maven3?),
>> but I do not want to get accidentally blocked by "oh, this change is not
>> allowed because it is not a CVE fix".
>> 
>> Matt>What we don’t want is to falsely advertise that v1 is still under
>> development
>> 
>> For instance, I do want to support new versions of v1.
>> If Logging PMC does not want advertise v1, that is fine. Would you donate
>> log4j 1.x code
>> to Incubator or to another PMC?
>> 
>> Matt>if we resurrect v1, then it’ll quickly become impossible to keep up
>> with all the activity given the size of the PMC
>> 
>> log4j v1 and log4j v2 are completely different products sharing the same
>> name.
>> So it won't be that surprising to have different people working on them.
>> 
>> Adding PMC members is one of the solutions. Donating the code to another
>> PMC is another solution.
>> 
>> I agree you have an unusual traffic spike now, however, multiple members of
>> Logging PMC do respond regarding v1,
>> and the overall intention is "Logging PMC is not interested in v1".
>> 
>> That is not something I want spending time on.
>> If I want to get v1 CVE fixed, I want to get it done and released. I do not
>> want to spend my time on "evangelizing v2, v3, or whatever".
>> 
>> Matt>we’d prefer to see more than one person working on that,
>> Matt>especially if we want to add more PMC members to oversee v1 in the
>> first place
>> 
>> Matt, this case is really unusual. Do you really want *multiple*
>> individuals to *actively* contribute to log4j v1
>> in order to add them to v1 PMC?
>> That is impossible. There's not much work to do in v1. There's no way I can
>> improve v1 code in a consistent and non-trivial way.
>> 
>> You should not be sitting and waiting for new v1 contributions to come.
>> 
>> So I would say it is not fair to say "there's not enough Logging PMC".
>> What needs to be done to add PMC members for v1?
>> 
>> Matt>users who haven’t bothered to upgrade in 10 years will have to end up
>> paying astronomical costs
>> 
>> There **is** possibility to maintain COBOL.
>> Currently, external contributions, including CVE fixes, are literally
>> blocked.
>> 
>> Matt>Or were people still using a mix of make or Ant?
>> 
>> People use Ant a lot, and there are new Ant releases:
>> https://ant.apache.org/antnews.html
>> 
>> Vladimir
>> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Looking for a champion: resurrect log4j 1.x

[Romain Manni-Bucau]

ok, so let's try to not create an endless thread:

1. where is the patch needed to fix the desired CVE? - must be compatible
with current svn trunk
2. please attach it to a ticket (or multiple if there are multiple fixes)
like LOG4J2-3219
3. if it does not get applied and PMC is opposed to get it applied let's
create a thread about it as being an issue and look for options but for now
the thread is looking for options which are not needed from my window

Hope it helps ot move the ball forward

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mer. 22 déc. 2021 à 06:24, Vladimir Sitnikov 
a écrit :

> Matt>Nobody in the Logging PMC is blocking a release here.
>
> Matt, thanks for the reply, however, it is false :(
> I see you are positive, however, many more replies were quite negative.
>
> Ralph Goers says: "We’ve stated several times that we don’t think
> resurrecting Log4j 1.x permanently is a good idea."
> https://lists.apache.org/thread/vz80p3v78xgposon3pcxbnb9729snnxt
>
> Gary Gregory says: "As I've stated before, IF there is a 1.2.18, it should
> ONLY be for CVEs,"
> https://lists.apache.org/thread/53h130p0kdkspn4kj2hq39vkgpyzgvp7
>
> They both are on Logging PMC, and they both have negative opinions on
> making progress with v1.
> I do not really understand what "ONLY be for CVEs" means (e.g. does it
> allow upgrading from Maven2 to Maven3?),
> but I do not want to get accidentally blocked by "oh, this change is not
> allowed because it is not a CVE fix".
>
> Matt>What we don’t want is to falsely advertise that v1 is still under
> development
>
> For instance, I do want to support new versions of v1.
> If Logging PMC does not want advertise v1, that is fine. Would you donate
> log4j 1.x code
> to Incubator or to another PMC?
>
> Matt>if we resurrect v1, then it’ll quickly become impossible to keep up
> with all the activity given the size of the PMC
>
> log4j v1 and log4j v2 are completely different products sharing the same
> name.
> So it won't be that surprising to have different people working on them.
>
> Adding PMC members is one of the solutions. Donating the code to another
> PMC is another solution.
>
> I agree you have an unusual traffic spike now, however, multiple members of
> Logging PMC do respond regarding v1,
> and the overall intention is "Logging PMC is not interested in v1".
>
> That is not something I want spending time on.
> If I want to get v1 CVE fixed, I want to get it done and released. I do not
> want to spend my time on "evangelizing v2, v3, or whatever".
>
> Matt>we’d prefer to see more than one person working on that,
> Matt>especially if we want to add more PMC members to oversee v1 in the
> first place
>
> Matt, this case is really unusual. Do you really want *multiple*
> individuals to *actively* contribute to log4j v1
> in order to add them to v1 PMC?
> That is impossible. There's not much work to do in v1. There's no way I can
> improve v1 code in a consistent and non-trivial way.
>
> You should not be sitting and waiting for new v1 contributions to come.
>
> So I would say it is not fair to say "there's not enough Logging PMC".
> What needs to be done to add PMC members for v1?
>
> Matt>users who haven’t bothered to upgrade in 10 years will have to end up
> paying astronomical costs
>
> There **is** possibility to maintain COBOL.
> Currently, external contributions, including CVE fixes, are literally
> blocked.
>
> Matt>Or were people still using a mix of make or Ant?
>
> People use Ant a lot, and there are new Ant releases:
> https://ant.apache.org/antnews.html
>
> Vladimir
>

Re: Looking for a champion: resurrect log4j 1.x

[Vladimir Sitnikov]

Matt>Nobody in the Logging PMC is blocking a release here.

Matt, thanks for the reply, however, it is false :(
I see you are positive, however, many more replies were quite negative.

Ralph Goers says: "We’ve stated several times that we don’t think
resurrecting Log4j 1.x permanently is a good idea."
https://lists.apache.org/thread/vz80p3v78xgposon3pcxbnb9729snnxt

Gary Gregory says: "As I've stated before, IF there is a 1.2.18, it should
ONLY be for CVEs,"
https://lists.apache.org/thread/53h130p0kdkspn4kj2hq39vkgpyzgvp7

They both are on Logging PMC, and they both have negative opinions on
making progress with v1.
I do not really understand what "ONLY be for CVEs" means (e.g. does it
allow upgrading from Maven2 to Maven3?),
but I do not want to get accidentally blocked by "oh, this change is not
allowed because it is not a CVE fix".

Matt>What we don’t want is to falsely advertise that v1 is still under
development

For instance, I do want to support new versions of v1.
If Logging PMC does not want advertise v1, that is fine. Would you donate
log4j 1.x code
to Incubator or to another PMC?

Matt>if we resurrect v1, then it’ll quickly become impossible to keep up
with all the activity given the size of the PMC

log4j v1 and log4j v2 are completely different products sharing the same
name.
So it won't be that surprising to have different people working on them.

Adding PMC members is one of the solutions. Donating the code to another
PMC is another solution.

I agree you have an unusual traffic spike now, however, multiple members of
Logging PMC do respond regarding v1,
and the overall intention is "Logging PMC is not interested in v1".

That is not something I want spending time on.
If I want to get v1 CVE fixed, I want to get it done and released. I do not
want to spend my time on "evangelizing v2, v3, or whatever".

Matt>we’d prefer to see more than one person working on that,
Matt>especially if we want to add more PMC members to oversee v1 in the
first place

Matt, this case is really unusual. Do you really want *multiple*
individuals to *actively* contribute to log4j v1
in order to add them to v1 PMC?
That is impossible. There's not much work to do in v1. There's no way I can
improve v1 code in a consistent and non-trivial way.

You should not be sitting and waiting for new v1 contributions to come.

So I would say it is not fair to say "there's not enough Logging PMC".
What needs to be done to add PMC members for v1?

Matt>users who haven’t bothered to upgrade in 10 years will have to end up
paying astronomical costs

There **is** possibility to maintain COBOL.
Currently, external contributions, including CVE fixes, are literally
blocked.

Matt>Or were people still using a mix of make or Ant?

People use Ant a lot, and there are new Ant releases:
https://ant.apache.org/antnews.html

Vladimir

Re: Looking for a champion: resurrect log4j 1.x

[Dave Fisher]

Sent from my iPhone

> On Dec 21, 2021, at 5:13 AM, Romain Manni-Bucau  wrote:
> 
> Le mar. 21 déc. 2021 à 12:33, Enrico Olivelli  a
> écrit :
> 
>> Vladimir,
>> I totally support this proposal.
>> 
>> Which are actually the steps we need to cut a release of log4j 1.x ?
>> - establish an Apache project ?
>> 
> 
> 1. Send a patch to apply on
> http://svn.apache.org/repos/asf/logging/log4j/trunk
> 
> 
>> - do the fix
>> 
> 
> 2. Get it applied
> 
> 
>> - cut a release
>> 
>> Can this be done inside another Apache Project who "adopts" the log4j
>> sources if the Logging Project doesn't want to do it ?
>> 
> 
> The PMC of log4j2 is logging project so it should be done there, if not the
> project can be forked inside Apache but should change of package until we
> get the perms to reuse the same one which means likely as much work as just
> getting it done at logging projec
> so hope it is not needed ;).
> 

If you think this is a problem then Apache members could ask the board to 
establish a new PMC to support log4j 1 including reusing the package.

Regards?
Dave
> 
>> 
>> Enrico
>> 
>> 
>> Il giorno mar 21 dic 2021 alle ore 08:36 Vladimir Sitnikov <
>> sitnikov.vladi...@gmail.com> ha scritto:
>> 
 Just wondering, is it even fulfilling the criteria of incubation?
>>> 
>>> I believe, the world does not need "active development in log4j 1.x"
>>> nowadays.
>>> What everybody needs from log4j 1.x is to fix security issues, fix
>>> outstanding issues (if any),
>>> keep the project buildable (e.g. avoid using outdated build systems),
>> etc.
>>> 
 it doesn't seem that sustainability is proven.
>>> 
>>> The problem is log4j 1.x is like COBOL of logging. There are apps that
>> are
>>> just stuck with log4j 1.x.
>>> The proof of sustainability is that lots of existing apps will never
>>> upgrade to 2.x because 2.x is incompatible.
>>> If the compatibility layer of 2.x would be improved to handle 99.999% of
>>> apps,
>>> then we could indeed move 1.x to the attic.
>>> 
>>> The Incubator Cookbook says:
 The ASF provides software for the public good,
>>> 
>>> As I described, log4j 2.x is not a direct replacement for log4j 1.x, and
>>> there are **lots** of applications
>>> that can't easily be upgraded to 2.x due to testing, configuration, and
>>> implementation issues.
>>> 
>>> The current Logging PMC is focused on log4j 2.x only, and they have no
>>> desire to release 1.x
>>> 
 active development but focus only on CVE fixes
>>> 
>>> I would say, the primary goal of resurrecting 1.x is to focus on CVEs,
>> and
>>> keep the project buildable and testable.
>>> However, it might be the case, that certain fixes or features would
>> appear.
>>> 
>>> The sad story is that the industry is using 1.x A LOT, and what Logging
>> PMC
>>> did was
>>> they ignored the community, and they just stopped maintaining 1.x and
>>> focused on an incompatible 2.x
>>> 
>>> Not only do they stop maintaining 1.x, but they also deny others to pick
>> up
>>> the maintenance task.
>>> 
>>> What I am trying to do now is to pick up that maintenance activity.
>>> 
>>> Vladimir
>>> 
>> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Looking for a champion: resurrect log4j 1.x

[Dave Fisher]

Sent from my iPhone

> On Dec 21, 2021, at 3:33 AM, Enrico Olivelli  wrote:
> 
> Vladimir,
> I totally support this proposal.
> 
> Which are actually the steps we need to cut a release of log4j 1.x ?
> - establish an Apache project ?
> - do the fix
> - cut a release
> 
> Can this be done inside another Apache Project who "adopts" the log4j
> sources if the Logging Project doesn't want to do it ?

Perhaps Apache Commons where log4j started?
> 
> Enrico
> 
> 
> Il giorno mar 21 dic 2021 alle ore 08:36 Vladimir Sitnikov <
> sitnikov.vladi...@gmail.com> ha scritto:
> 
>>> Just wondering, is it even fulfilling the criteria of incubation?
>> 
>> I believe, the world does not need "active development in log4j 1.x"
>> nowadays.
>> What everybody needs from log4j 1.x is to fix security issues, fix
>> outstanding issues (if any),
>> keep the project buildable (e.g. avoid using outdated build systems), etc.
>> 
>>> it doesn't seem that sustainability is proven.
>> 
>> The problem is log4j 1.x is like COBOL of logging. There are apps that are
>> just stuck with log4j 1.x.
>> The proof of sustainability is that lots of existing apps will never
>> upgrade to 2.x because 2.x is incompatible.
>> If the compatibility layer of 2.x would be improved to handle 99.999% of
>> apps,
>> then we could indeed move 1.x to the attic.
>> 
>> The Incubator Cookbook says:
>>> The ASF provides software for the public good,
>> 
>> As I described, log4j 2.x is not a direct replacement for log4j 1.x, and
>> there are **lots** of applications
>> that can't easily be upgraded to 2.x due to testing, configuration, and
>> implementation issues.
>> 
>> The current Logging PMC is focused on log4j 2.x only, and they have no
>> desire to release 1.x
>> 
>>> active development but focus only on CVE fixes
>> 
>> I would say, the primary goal of resurrecting 1.x is to focus on CVEs, and
>> keep the project buildable and testable.
>> However, it might be the case, that certain fixes or features would appear.
>> 
>> The sad story is that the industry is using 1.x A LOT, and what Logging PMC
>> did was
>> they ignored the community, and they just stopped maintaining 1.x and
>> focused on an incompatible 2.x
>> 
>> Not only do they stop maintaining 1.x, but they also deny others to pick up
>> the maintenance task.
>> 
>> What I am trying to do now is to pick up that maintenance activity.
>> 
>> Vladimir
>> 

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Looking for a champion: resurrect log4j 1.x

[Dave Fisher]

Hi,

Have you discussed the approach you outlined with the logging PMC? It seems to 
me the idea of a drop in jar that allows log4j 1 over log4j  2 is an ideal 
product for that PMC to support.

All the best,
Dave

Sent from my iPhone

> On Dec 21, 2021, at 8:22 PM, 张铎  wrote:
> 
> I'm the one who migrated HBase from log4j to log4j2, and still tries to
> migrate hadoop but still can not find a suitable upgrading path...
> 
> For me, I do not prefer we release a new log4j 1.x, it has been EOL for
> many years, we should encourage people to upgrade to a newer logging
> framework. FWIW, even if we make a new release for log4j, the projects
> which rely on log4j still need to upgrade and make a new release right?
> 
> So then, I stand with Andrew's point, why people post an email here to get
> a new release for log4j 1.x, is mainly because they can not easily migrate
> to log4j2. If the log4j to log4j2 bridge can work perfectly, then for most
> old projects, they can just add a log4j12 bridge in the dependencies to
> solve most problems. And then they could start to migrate to pure log4j2
> incrementally and finally remove the log4j12 bridge.
> 
> But in my experience, first, the log4j12 bridge is not perfect. For
> example, since hadoop is still on log4j 1.x, I need to add log4j12 bridge
> dependency if I want to run UTs based on hadoop mini cluster, and then I
> need to manually copy some code from log4j1 in order to make it work, this
> is an example
> 
> https://github.com/apache/hbase/blob/master/hbase-logging/src/test/java/org/apache/log4j/FileAppender.java
> 
> I know in the bridge you will create log4j2 appender instead when reading
> the configuration file of log4j1, but since the appenders in log4j1 lack of
> some abilities, it is common that lots of projects will implement their own
> appender, I think we should take care of these usages and make them migrate
> smoothly.
> 
> And then, while fully migrating to log4j2, there is another annoying
> problem, the
> 
> log4j.rootLogger=INFO,console
> 
> grammar is gone! It is used among almost all the projects I've seen, and we
> just drop the support for it!
> 
> In HBase, I have to do some magics in the start scripts to avoid breaking
> our users too much
> 
> https://github.com/apache/hbase/blob/314e924e960d0d5c0c5e8ec436c75aaa6190b4c1/bin/hbase#L829
> 
> I really hope we could do better on backward compatibility, so when people
> ask for something about log4j1, we could just tell them to add the bridge
> to log4j2. And then easily fully migrate to log4j2 without too much effort
> if they want to use more features of log4j2, instead of finally making
> people ask here on whether they could revive log4j1...
> 
> That's my real feeling while working on migrating from log4j1 to log4j2.
> Please correct me if I'm wrong. I'm also willing to help here on making the
> bridge works better and also making the migration easier.
> 
> Thanks.
> 
> 
> 
> 
> 
> Andrew Purtell  于2021年12月22日周三 05:55写道：
> 
>>> as for the v1 :: COBOL analogy, that’s not a bad comparison. Basically,
>> users who haven’t bothered to upgrade in 10 years will have to end up
>> paying astronomical costs for consultants who can still work on ancient
>> software effectively to help modify their systems.
>> 
>> I have to take some exception to this. If the log4j 2.x configuration files
>> were compatible _enough_ with 1.x then taking this position would be
>> understandable. However, because they are not compatible in the way that
>> users require -- and the backwards compatibility is still marked as
>> 'experimental', even -- it is not great to blame users "who haven't
>> bothered to upgrade in 10 years". Turning this around, why is backwards
>> compatibility still experimental after 10 years? I am involved with several
>> Apache projects where we would love to upgrade from log4j 1 to log4j 2, and
>> have been talking about it for _years_. However, we have not been able to
>> easily do so because we actually care about operational cross-version
>> compatibility for our users. On some of these projects we are still stuck
>> on log4j 1.
>> 
>> I also support continuing releasing for log4j 1.x, and would volunteer some
>> of my time to assist in the effort.
>> 
>> 
>> On Tue, Dec 21, 2021 at 12:34 PM Matt Sicker  wrote:
>> 
>>> Nobody in the Logging PMC is blocking a release here. What we don’t want
>>> is to falsely advertise that v1 is still under development. We already
>> have
>>> a huge increase in mailing list, PR, and other traffic ever since
>>> Log4Shell, and if we resurrect v1, then it’ll quickly become impossible
>> to
>>> keep up with all the activity given the size of the PMC. If any
>> non-trivial
>>> work is to be done in v1, we’d prefer to see more than one person working
>>> on that, especially if we want to add more PMC members to oversee v1 in
>> the
>>> first place.
>>> 
>>> And as for the v1 :: COBOL analogy, that’s not a bad comparison.
>>> Basically, users who haven’t 

Re: Looking for a champion: resurrect log4j 1.x

[Duo Zhang]

I'm the one who migrated HBase from log4j to log4j2, and still tries to
migrate hadoop but still can not find a suitable upgrading path...

For me, I do not prefer we release a new log4j 1.x, it has been EOL for
many years, we should encourage people to upgrade to a newer logging
framework. FWIW, even if we make a new release for log4j, the projects
which rely on log4j still need to upgrade and make a new release right?

So then, I stand with Andrew's point, why people post an email here to get
a new release for log4j 1.x, is mainly because they can not easily migrate
to log4j2. If the log4j to log4j2 bridge can work perfectly, then for most
old projects, they can just add a log4j12 bridge in the dependencies to
solve most problems. And then they could start to migrate to pure log4j2
incrementally and finally remove the log4j12 bridge.

But in my experience, first, the log4j12 bridge is not perfect. For
example, since hadoop is still on log4j 1.x, I need to add log4j12 bridge
dependency if I want to run UTs based on hadoop mini cluster, and then I
need to manually copy some code from log4j1 in order to make it work, this
is an example

https://github.com/apache/hbase/blob/master/hbase-logging/src/test/java/org/apache/log4j/FileAppender.java

I know in the bridge you will create log4j2 appender instead when reading
the configuration file of log4j1, but since the appenders in log4j1 lack of
some abilities, it is common that lots of projects will implement their own
appender, I think we should take care of these usages and make them migrate
smoothly.

And then, while fully migrating to log4j2, there is another annoying
problem, the

log4j.rootLogger=INFO,console

grammar is gone! It is used among almost all the projects I've seen, and we
just drop the support for it!

In HBase, I have to do some magics in the start scripts to avoid breaking
our users too much

https://github.com/apache/hbase/blob/314e924e960d0d5c0c5e8ec436c75aaa6190b4c1/bin/hbase#L829

I really hope we could do better on backward compatibility, so when people
ask for something about log4j1, we could just tell them to add the bridge
to log4j2. And then easily fully migrate to log4j2 without too much effort
if they want to use more features of log4j2, instead of finally making
people ask here on whether they could revive log4j1...

That's my real feeling while working on migrating from log4j1 to log4j2.
Please correct me if I'm wrong. I'm also willing to help here on making the
bridge works better and also making the migration easier.

Thanks.





Andrew Purtell  于2021年12月22日周三 05:55写道：

> > as for the v1 :: COBOL analogy, that’s not a bad comparison. Basically,
> users who haven’t bothered to upgrade in 10 years will have to end up
> paying astronomical costs for consultants who can still work on ancient
> software effectively to help modify their systems.
>
> I have to take some exception to this. If the log4j 2.x configuration files
> were compatible _enough_ with 1.x then taking this position would be
> understandable. However, because they are not compatible in the way that
> users require -- and the backwards compatibility is still marked as
> 'experimental', even -- it is not great to blame users "who haven't
> bothered to upgrade in 10 years". Turning this around, why is backwards
> compatibility still experimental after 10 years? I am involved with several
> Apache projects where we would love to upgrade from log4j 1 to log4j 2, and
> have been talking about it for _years_. However, we have not been able to
> easily do so because we actually care about operational cross-version
> compatibility for our users. On some of these projects we are still stuck
> on log4j 1.
>
> I also support continuing releasing for log4j 1.x, and would volunteer some
> of my time to assist in the effort.
>
>
> On Tue, Dec 21, 2021 at 12:34 PM Matt Sicker  wrote:
>
> > Nobody in the Logging PMC is blocking a release here. What we don’t want
> > is to falsely advertise that v1 is still under development. We already
> have
> > a huge increase in mailing list, PR, and other traffic ever since
> > Log4Shell, and if we resurrect v1, then it’ll quickly become impossible
> to
> > keep up with all the activity given the size of the PMC. If any
> non-trivial
> > work is to be done in v1, we’d prefer to see more than one person working
> > on that, especially if we want to add more PMC members to oversee v1 in
> the
> > first place.
> >
> > And as for the v1 :: COBOL analogy, that’s not a bad comparison.
> > Basically, users who haven’t bothered to upgrade in 10 years will have to
> > end up paying astronomical costs for consultants who can still work on
> > ancient software effectively to help modify their systems. Was Maven even
> > widely used back when v1 was popular? Or were people still using a mix of
> > make or Ant?
> > --
> > Matt Sicker
> >
> > > On Dec 21, 2021, at 07:13, Romain Manni-Bucau 
> > wrote:
> > >
> > > Le mar. 21 déc. 2021 à 12:33, Enrico 

Re: Looking for a champion: resurrect log4j 1.x

[Andrew Purtell]

> as for the v1 :: COBOL analogy, that’s not a bad comparison. Basically,
users who haven’t bothered to upgrade in 10 years will have to end up
paying astronomical costs for consultants who can still work on ancient
software effectively to help modify their systems.

I have to take some exception to this. If the log4j 2.x configuration files
were compatible _enough_ with 1.x then taking this position would be
understandable. However, because they are not compatible in the way that
users require -- and the backwards compatibility is still marked as
'experimental', even -- it is not great to blame users "who haven't
bothered to upgrade in 10 years". Turning this around, why is backwards
compatibility still experimental after 10 years? I am involved with several
Apache projects where we would love to upgrade from log4j 1 to log4j 2, and
have been talking about it for _years_. However, we have not been able to
easily do so because we actually care about operational cross-version
compatibility for our users. On some of these projects we are still stuck
on log4j 1.

I also support continuing releasing for log4j 1.x, and would volunteer some
of my time to assist in the effort.


On Tue, Dec 21, 2021 at 12:34 PM Matt Sicker  wrote:

> Nobody in the Logging PMC is blocking a release here. What we don’t want
> is to falsely advertise that v1 is still under development. We already have
> a huge increase in mailing list, PR, and other traffic ever since
> Log4Shell, and if we resurrect v1, then it’ll quickly become impossible to
> keep up with all the activity given the size of the PMC. If any non-trivial
> work is to be done in v1, we’d prefer to see more than one person working
> on that, especially if we want to add more PMC members to oversee v1 in the
> first place.
>
> And as for the v1 :: COBOL analogy, that’s not a bad comparison.
> Basically, users who haven’t bothered to upgrade in 10 years will have to
> end up paying astronomical costs for consultants who can still work on
> ancient software effectively to help modify their systems. Was Maven even
> widely used back when v1 was popular? Or were people still using a mix of
> make or Ant?
> --
> Matt Sicker
>
> > On Dec 21, 2021, at 07:13, Romain Manni-Bucau 
> wrote:
> >
> > Le mar. 21 déc. 2021 à 12:33, Enrico Olivelli  a
> > écrit :
> >
> >> Vladimir,
> >> I totally support this proposal.
> >>
> >> Which are actually the steps we need to cut a release of log4j 1.x ?
> >> - establish an Apache project ?
> >>
> >
> > 1. Send a patch to apply on
> > http://svn.apache.org/repos/asf/logging/log4j/trunk
> >
> >
> >> - do the fix
> >>
> >
> > 2. Get it applied
> >
> >
> >> - cut a release
> >>
> >> Can this be done inside another Apache Project who "adopts" the log4j
> >> sources if the Logging Project doesn't want to do it ?
> >>
> >
> > The PMC of log4j2 is logging project so it should be done there, if not
> the
> > project can be forked inside Apache but should change of package until we
> > get the perms to reuse the same one which means likely as much work as
> just
> > getting it done at logging project so hope it is not needed ;).
> >
> >
> >>
> >> Enrico
> >>
> >>
> >> Il giorno mar 21 dic 2021 alle ore 08:36 Vladimir Sitnikov <
> >> sitnikov.vladi...@gmail.com> ha scritto:
> >>
>  Just wondering, is it even fulfilling the criteria of incubation?
> >>>
> >>> I believe, the world does not need "active development in log4j 1.x"
> >>> nowadays.
> >>> What everybody needs from log4j 1.x is to fix security issues, fix
> >>> outstanding issues (if any),
> >>> keep the project buildable (e.g. avoid using outdated build systems),
> >> etc.
> >>>
>  it doesn't seem that sustainability is proven.
> >>>
> >>> The problem is log4j 1.x is like COBOL of logging. There are apps that
> >> are
> >>> just stuck with log4j 1.x.
> >>> The proof of sustainability is that lots of existing apps will never
> >>> upgrade to 2.x because 2.x is incompatible.
> >>> If the compatibility layer of 2.x would be improved to handle 99.999%
> of
> >>> apps,
> >>> then we could indeed move 1.x to the attic.
> >>>
> >>> The Incubator Cookbook says:
>  The ASF provides software for the public good,
> >>>
> >>> As I described, log4j 2.x is not a direct replacement for log4j 1.x,
> and
> >>> there are **lots** of applications
> >>> that can't easily be upgraded to 2.x due to testing, configuration, and
> >>> implementation issues.
> >>>
> >>> The current Logging PMC is focused on log4j 2.x only, and they have no
> >>> desire to release 1.x
> >>>
>  active development but focus only on CVE fixes
> >>>
> >>> I would say, the primary goal of resurrecting 1.x is to focus on CVEs,
> >> and
> >>> keep the project buildable and testable.
> >>> However, it might be the case, that certain fixes or features would
> >> appear.
> >>>
> >>> The sad story is that the industry is using 1.x A LOT, and what Logging
> >> PMC
> >>> did was
> >>> they ignored the community, and they just stopped 

Re: Looking for a champion: resurrect log4j 1.x

[Matt Sicker]

Nobody in the Logging PMC is blocking a release here. What we don’t want is to 
falsely advertise that v1 is still under development. We already have a huge 
increase in mailing list, PR, and other traffic ever since Log4Shell, and if we 
resurrect v1, then it’ll quickly become impossible to keep up with all the 
activity given the size of the PMC. If any non-trivial work is to be done in 
v1, we’d prefer to see more than one person working on that, especially if we 
want to add more PMC members to oversee v1 in the first place.

And as for the v1 :: COBOL analogy, that’s not a bad comparison. Basically, 
users who haven’t bothered to upgrade in 10 years will have to end up paying 
astronomical costs for consultants who can still work on ancient software 
effectively to help modify their systems. Was Maven even widely used back when 
v1 was popular? Or were people still using a mix of make or Ant?
--
Matt Sicker

> On Dec 21, 2021, at 07:13, Romain Manni-Bucau  wrote:
> 
> Le mar. 21 déc. 2021 à 12:33, Enrico Olivelli  a
> écrit :
> 
>> Vladimir,
>> I totally support this proposal.
>> 
>> Which are actually the steps we need to cut a release of log4j 1.x ?
>> - establish an Apache project ?
>> 
> 
> 1. Send a patch to apply on
> http://svn.apache.org/repos/asf/logging/log4j/trunk
> 
> 
>> - do the fix
>> 
> 
> 2. Get it applied
> 
> 
>> - cut a release
>> 
>> Can this be done inside another Apache Project who "adopts" the log4j
>> sources if the Logging Project doesn't want to do it ?
>> 
> 
> The PMC of log4j2 is logging project so it should be done there, if not the
> project can be forked inside Apache but should change of package until we
> get the perms to reuse the same one which means likely as much work as just
> getting it done at logging project so hope it is not needed ;).
> 
> 
>> 
>> Enrico
>> 
>> 
>> Il giorno mar 21 dic 2021 alle ore 08:36 Vladimir Sitnikov <
>> sitnikov.vladi...@gmail.com> ha scritto:
>> 
 Just wondering, is it even fulfilling the criteria of incubation?
>>> 
>>> I believe, the world does not need "active development in log4j 1.x"
>>> nowadays.
>>> What everybody needs from log4j 1.x is to fix security issues, fix
>>> outstanding issues (if any),
>>> keep the project buildable (e.g. avoid using outdated build systems),
>> etc.
>>> 
 it doesn't seem that sustainability is proven.
>>> 
>>> The problem is log4j 1.x is like COBOL of logging. There are apps that
>> are
>>> just stuck with log4j 1.x.
>>> The proof of sustainability is that lots of existing apps will never
>>> upgrade to 2.x because 2.x is incompatible.
>>> If the compatibility layer of 2.x would be improved to handle 99.999% of
>>> apps,
>>> then we could indeed move 1.x to the attic.
>>> 
>>> The Incubator Cookbook says:
 The ASF provides software for the public good,
>>> 
>>> As I described, log4j 2.x is not a direct replacement for log4j 1.x, and
>>> there are **lots** of applications
>>> that can't easily be upgraded to 2.x due to testing, configuration, and
>>> implementation issues.
>>> 
>>> The current Logging PMC is focused on log4j 2.x only, and they have no
>>> desire to release 1.x
>>> 
 active development but focus only on CVE fixes
>>> 
>>> I would say, the primary goal of resurrecting 1.x is to focus on CVEs,
>> and
>>> keep the project buildable and testable.
>>> However, it might be the case, that certain fixes or features would
>> appear.
>>> 
>>> The sad story is that the industry is using 1.x A LOT, and what Logging
>> PMC
>>> did was
>>> they ignored the community, and they just stopped maintaining 1.x and
>>> focused on an incompatible 2.x
>>> 
>>> Not only do they stop maintaining 1.x, but they also deny others to pick
>> up
>>> the maintenance task.
>>> 
>>> What I am trying to do now is to pick up that maintenance activity.
>>> 
>>> Vladimir
>>> 
>> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Looking for a champion: resurrect log4j 1.x

[Romain Manni-Bucau]

Le mar. 21 déc. 2021 à 12:33, Enrico Olivelli  a
écrit :

> Vladimir,
> I totally support this proposal.
>
> Which are actually the steps we need to cut a release of log4j 1.x ?
> - establish an Apache project ?
>

1. Send a patch to apply on
http://svn.apache.org/repos/asf/logging/log4j/trunk


> - do the fix
>

2. Get it applied


> - cut a release
>
> Can this be done inside another Apache Project who "adopts" the log4j
> sources if the Logging Project doesn't want to do it ?
>

The PMC of log4j2 is logging project so it should be done there, if not the
project can be forked inside Apache but should change of package until we
get the perms to reuse the same one which means likely as much work as just
getting it done at logging project so hope it is not needed ;).


>
> Enrico
>
>
> Il giorno mar 21 dic 2021 alle ore 08:36 Vladimir Sitnikov <
> sitnikov.vladi...@gmail.com> ha scritto:
>
> > >Just wondering, is it even fulfilling the criteria of incubation?
> >
> > I believe, the world does not need "active development in log4j 1.x"
> > nowadays.
> > What everybody needs from log4j 1.x is to fix security issues, fix
> > outstanding issues (if any),
> > keep the project buildable (e.g. avoid using outdated build systems),
> etc.
> >
> > >it doesn't seem that sustainability is proven.
> >
> > The problem is log4j 1.x is like COBOL of logging. There are apps that
> are
> > just stuck with log4j 1.x.
> > The proof of sustainability is that lots of existing apps will never
> > upgrade to 2.x because 2.x is incompatible.
> > If the compatibility layer of 2.x would be improved to handle 99.999% of
> > apps,
> > then we could indeed move 1.x to the attic.
> >
> > The Incubator Cookbook says:
> > >The ASF provides software for the public good,
> >
> > As I described, log4j 2.x is not a direct replacement for log4j 1.x, and
> > there are **lots** of applications
> > that can't easily be upgraded to 2.x due to testing, configuration, and
> > implementation issues.
> >
> > The current Logging PMC is focused on log4j 2.x only, and they have no
> > desire to release 1.x
> >
> > >active development but focus only on CVE fixes
> >
> > I would say, the primary goal of resurrecting 1.x is to focus on CVEs,
> and
> > keep the project buildable and testable.
> > However, it might be the case, that certain fixes or features would
> appear.
> >
> > The sad story is that the industry is using 1.x A LOT, and what Logging
> PMC
> > did was
> > they ignored the community, and they just stopped maintaining 1.x and
> > focused on an incompatible 2.x
> >
> > Not only do they stop maintaining 1.x, but they also deny others to pick
> up
> > the maintenance task.
> >
> > What I am trying to do now is to pick up that maintenance activity.
> >
> > Vladimir
> >
>

Re: Looking for a champion: resurrect log4j 1.x

[Enrico Olivelli]

Vladimir,
I totally support this proposal.

Which are actually the steps we need to cut a release of log4j 1.x ?
- establish an Apache project ?
- do the fix
- cut a release

Can this be done inside another Apache Project who "adopts" the log4j
sources if the Logging Project doesn't want to do it ?

Enrico


Il giorno mar 21 dic 2021 alle ore 08:36 Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> ha scritto:

> >Just wondering, is it even fulfilling the criteria of incubation?
>
> I believe, the world does not need "active development in log4j 1.x"
> nowadays.
> What everybody needs from log4j 1.x is to fix security issues, fix
> outstanding issues (if any),
> keep the project buildable (e.g. avoid using outdated build systems), etc.
>
> >it doesn't seem that sustainability is proven.
>
> The problem is log4j 1.x is like COBOL of logging. There are apps that are
> just stuck with log4j 1.x.
> The proof of sustainability is that lots of existing apps will never
> upgrade to 2.x because 2.x is incompatible.
> If the compatibility layer of 2.x would be improved to handle 99.999% of
> apps,
> then we could indeed move 1.x to the attic.
>
> The Incubator Cookbook says:
> >The ASF provides software for the public good,
>
> As I described, log4j 2.x is not a direct replacement for log4j 1.x, and
> there are **lots** of applications
> that can't easily be upgraded to 2.x due to testing, configuration, and
> implementation issues.
>
> The current Logging PMC is focused on log4j 2.x only, and they have no
> desire to release 1.x
>
> >active development but focus only on CVE fixes
>
> I would say, the primary goal of resurrecting 1.x is to focus on CVEs, and
> keep the project buildable and testable.
> However, it might be the case, that certain fixes or features would appear.
>
> The sad story is that the industry is using 1.x A LOT, and what Logging PMC
> did was
> they ignored the community, and they just stopped maintaining 1.x and
> focused on an incompatible 2.x
>
> Not only do they stop maintaining 1.x, but they also deny others to pick up
> the maintenance task.
>
> What I am trying to do now is to pick up that maintenance activity.
>
> Vladimir
>