One person's EOL is another person's open source business model ! (RHEL subscriptions are not cheap!)
Anyway, quick FYI - I noticed Atlassian has rev'd log4j-1.2.17 fifteen times ! Might be some good patches in there. They do publish the "sources.jar": https://packages.atlassian.com/3rdparty/log4j/log4j/1.2.17-atlassian-15/ yours, Julius On Fri, Jan 7, 2022 at 11:59 AM Dominik Psenner <dpsen...@gmail.com> wrote: > 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 <boa...@gmail.com> 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 <marlow.age...@gmail.com> > > wrote: > > > > > > my comment is below: > > > > > > On Fri, 7 Jan 2022 at 14:23, Christian Grobmeier <grobme...@apache.org > > > > > 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 > > > > > > >
