Hi all,
Note that the statement on the EOL site is incorrect:
"The reload4j project provides a drop-in replacement for Log4j 1.x with
maintenance and security fixes."
It certainly is not a "drop-in replacement" because it ripped out public
classes and so breaks binary compatibility. It's more of
Hi Gary,
On 16.11.2024 17:41, Gary Gregory wrote:
[1]https://github.com/apache/logging-log4j2/issues/3143
This issue points to the merged PR
https://github.com/apache/logging-log4j2/pull/2936, a large change set with
zero tests. This isn't great since there are no tests to catch regressions
:-(
Hi Piotr,
Thanks for the details. The good new is that it was caught fairly quickly.
Looking forward to reviewing the RC...
Gary
On Sat, Nov 16, 2024, 12:06 PM Piotr P. Karwasz
wrote:
> Hi Gary,
>
> On 16.11.2024 17:41, Gary Gregory wrote:
> > [1]https://github.com/apache/logging-log4j2/issues
Hi All,
Thank you Piotr for managing this release.
[1] https://github.com/apache/logging-log4j2/issues/3143
This issue points to the merged PR
https://github.com/apache/logging-log4j2/pull/2936, a large change set with
zero tests. This isn't great since there are no tests to catch regressions
:-
Hi all,
Due to bug #3143[1], which allows a `Logger` to be garbage-collected
before it is returned by `LoggerContext#getLogger()`, I am planning a
2.24.2 release with just two changes:
* A fix for the above mentioned bug (see PR #3209[2]).
* A fix for a bug related to `ThreadContextMap` (see
Hi Ralph,
On 14.11.2024 06:50, Ralph Goers wrote:
Log4j 2.3.x and 2.12.x don’t need votes. We declared that we were no longer
supporting Java 6 and then Java 7 and that those would be the last releases to
do so. We made an exception for Log4Shell and created patches for both since
the securit
