End-Of-Life means End-Of-Life and that is the end of the story. If someone keeps patching an End-Of-Life component, how should downstream understand when they should update their product?
The answer to this question is the technical definition of End-Of-Life. Upgrade, migrate, rewrite, throw away, whatever, .. log4j1 builds on top of End-Of-Life stuff like java 1.4 and has been dead for a decade. Stop living in the past, the future is now! -- Sent from my phone. Typos are a kind gift to anyone who happens to find them. On Fri, Jan 7, 2022, 19:38 Matt Sicker <[email protected]> wrote: > https://github.com/albfernandez/log4j/ is one fork I found that > published a fixed copy on Maven Central. Confluent also publishes a > forked copy, though I don't know where their source code is (package > names are renamed as it's mainly used by old versions of Confluent's > hosted services, so it's possible that the source code isn't > published). > > One of the key missing pieces I've seen in other forks so far is that > they simply ripped a lot of affected code out of the library entirely > which is sure to cause compatibility issues when attempted to be used > as a drop-in replacement. At least the patched versions in RHEL and > Debian are mainly used by other RHEL or Debian packages, so they > already have their own compatibility policies. While I'd imagine Ceki > is one of the only people in the world who could figure out how to > update the old build, it'd also be great to respond to relevant > threads about this while they're active rather than waiting until > after the bell rings. As Christian said, if the work is done outside > the ASF to get a full release working for 1.2.x, then I think we'd be > more receptive to accepting it back and making a release, especially > if there is continued community interest in it. Otherwise, I still > believe it's more useful to patch up the existing v2/v1 compatibility > system so that users can drop in v2 to upgrade things much more > easily, especially given the intractability of many concurrency issues > in v1 that are fairly unacceptable in modern Java applications. > > On Fri, Jan 7, 2022 at 12:18 PM Andrew Marlow <[email protected]> > wrote: > > > > my comment is below: > > > > On Fri, 7 Jan 2022 at 14:23, Christian Grobmeier <[email protected]> > > wrote: > > > > > Hello, > > > > > > On Fri, Jan 7, 2022, at 08:21, Ceki Gülcü wrote: > > > > As for infringing on the log4j trademark, I will rename the repo to > > > > something else, for example "re4j". > > > > > > > > As mentioned in my previous message, if the ASF decides to integrate > > > > "re4j" as log4j 1.x, the door is open. > > > > > > Thanks. You did not respond to my earlier question why this is so > urgent > > > after 10 years, > > > but I guess we see what you are trying to do on the fork. > > > > > > If we feel this is valuable, we may vote again. Thanks for keeping that > > > door open. I think working on a fork is the best way at this point of > time. > > > > > > > I want to add my thanks to Ceki as well. I would like to see log4j-v1 get > > one fix in version 1.2.18 which RedHat have already made for RHEL7. It's > > the one for the SocketServer issue. The source for this fix is out there > > somewhere. I did track it down some time ago but I 've forgotten where I > > found it. Maybe Matt knows where it is, then it could be applied to this > > fork. > > > > > > > Good luck. > > > > > > Kind regards, > > > Christian > > > >
