> On Apr 8, 2024, at 2:40 PM, Jochen Wiedmann <jochen.wiedm...@gmail.com> wrote:
>
> On Mon, Apr 8, 2024 at 1:11 PM Apache <ralph.go...@dslextreme.com> wrote:
>
>> My opinion is to drop it from 3.0.0. 2.x is going to live a long time still.
>> By the time it dies Log4J 1.x will have been dead well over 15 years, maybe
>> even 20. That would give users plenty of time to be aware that they need to
>> plan to upgrade.
>
> How long ago was it, that all these JNDI, and JMS related issues where
> found? Yes, three years. And I remember very well, how customers
> basically stormed my employers house, because some ancient code (which
> should have been updated years ago) is using these "dead" libraries.
>
> And, do you remember also, how long it took at the time, to push out
> 1.2.18? Wait, that was never published? Instead, we have
> https://github.com/qos-ch/reload4j.
>
> Please, just because you think, that you can master these things:
> Don't assume, that others can.
I think you missed the point. Log4j 3.x will ONLY support Java 17 and above.
That would mean that someone would have had to port & verify that code written
for pre-Java 6 now runs on Java 17+ in order to use Log4j 3.x to support their
Log4j 1.x application.
As I said, Log4j 2.x isn’t going away any time soon. Even then, I suspect that
log4j-1.2-api from Log4j 2.x will probably work with the rest of Log4j 3.x
especially now that Log4j API is staying at 2.x (although at some point its
minimum JDK will be upgraded). It is possible that we may decide to fork the
1.2 API module into its own repo after the rest of 2.x is retired. Who knows?
That will be years from now.
All we are deciding here is to NOT include it in 3.x.
Ralph
