Hey Gary,
Thanks for your thoughts.
TL;DR: I actually share your preference! But: how? Also, progress notes.
In a "normal" situation I really think that the 99% drop in replacement
that is already there is plenty.
Especially from an ASF perspective where our primary deliverable is source
code to developers, I think the 1.x to 2.x upgrade path is already quite
excellent.
If you have source code under management and you can do a recompile or
rebuild of your software it's all but automatic.
The people I want to help also right now are (rightly) conservative
sysadmins.
People responsible for vital infrastructure at banks, energy companies,
government, etc.
They need a fool-proof solution that they can deploy in the next few
days/weeks/months.
Long before they can install a new release from their java software vendors.
These people should not be running vital systems based on software that was
end-of-life years ago...
...but they are, and log4j 1.2 is inside lots and lots of them.
I think it's possible to get a 99.9% compatible drop in replacement by
starting from the 1.2 codebase.
I think we can do it with limited effort of low complexity.
I think we can do it in a way that is also easy to audit/verify.
Low-risk to the level that you might do it during an end-of-year change
freeze at a core bank.
I think that this reduces their risk//exposure/worry/compliance nightmare.
Low-risk to the point that it can be easier to swap out a jar file than to
verify they don't need to.
Running tools like this in patch mode:
https://github.com/dtact/divd-2021-00038--log4j-scanner
If it's also possible to get a 99.9% compatible drop in replacement jar
based on the 2.x codebase I completely agree that would be preferable.
But I could not see a straightforward way.
To me it seems to require, like you say, significant brainpower.
I also guess it is much more effort because of the java versions.
Work would start with refactoring 2.x for compatibility with JDK1.4/5/6.
Do you really want to do that to 2.x?
For me personally, this route would have to start with learning log4j2 in
depth.
So I see no way to contribute significantly, soon.
Meanwhile I think I am mostly done getting the 1.2.x build and site cleaned
up...
https://github.com/lsimons/log4j/commit/cfa9012d9eaee0f2083db3a62b8428bd229b9e6f
So tentatively started some code cleanup...
https://github.com/lsimons/log4j/commit/cdb674ea6a89db9b64ddc34d3e57e82c537e4b41
https://github.com/lsimons/log4j/commit/c11c645013bbbe3da0bbe1fcef4a0fae97e2dc48
Could really do with opinions on the approach.
Tomorrow (I'm in CET) I plan to work on setting up some
regression/integration testing tooling.
Get some sample 'old' system using old log4j, drop in replacement, show it
works.
(Did anyone start on that already?)
Cheers,
Leo
On Thu, Dec 16, 2021 at 2:36 PM Gary Gregory <garydgreg...@gmail.com> wrote:
> Hi all,
>
> [Reposting in a new thread]
>
> Log4j 2 provides a compatibility layer for the 1.2 API and for some
> configuration files. It is not a 100% drop in replacement, but it could be
> made much better with some work. So, I would prefer that brain power for
> 1.x be applied in this direction, instead of resurrecting the 1.x line
> which is end-of-life since 2015, such that we could say update to 2.x and
> pow, it works :-)
>
> Gary
>
