On Sat, Jan 8, 2022, at 05:11, Julius Davies wrote:
> One person's EOL is another person's open source business model ! (RHEL
> subscriptions are not cheap!)
I doubt anybody would actually pay for log4j.
>
> 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/
Didn’t look at the code, but I wonder why and what they did in those revs.
I got my customers to upgrade and still think this is what should be done. V1
has so many problems I am still confused people just don’t upgrade but stay
with eol software.
>
>
> yours,
>
> Julius
>
>
>
>
> On Fri, Jan 7, 2022 at 11:59 AM Dominik Psenner <[email protected]> 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 <[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
>> > > >
>> >
>>
