Did we make a decision on this? Ralph
> On Apr 8, 2024, at 4:02 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > > >> 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
