> On Nov 3, 2023, at 10:08 PM, Christian Grobmeier <grobme...@apache.org> wrote:
>
>
>> However, like myself, organizations are not going to delay upgrading
>> too long. Having Log4j 3.x be available before the majority of orgs
>> switch to Spring 3 will greatly improve its adoption.
>
> Agreed, the earlier, so better, but making Log4j 3.x GA "first thing next
> year" seems to be quite of a rush.
“Quite of a rush”? Really?
The first code commit of Log4j 2.x was performed by me in May 2010. The first
alpha release was in July 2012. 2.0 GA was in July 2014. That is approximately
4 years from first commit to GA with one more alpha, 9 betas, and 2 release
candidates in between.
In contrast, the release-2.x branch was created in Jan 2018 which left master
for work on 3.x to begin. The first, and only so far, release was in June of
this year. That is over 5 years from the initial branch to first release.
To make matters worse, Log4j 2.x was brand new code. I borrowed from Log4j
extras for some of the rolling file appender stuff but everything else was
written from scratch. In contrast, 3.x started from 2.x and has largely been
refactoring work. So the risks involved with 3.x are much, much lower than what
we faced with 2.x.
So I have no idea how you can use the word “rushed” to describe the abysmal
pace 3.x has been proceeding.
>
> As far as I know, we still have changes in 2.x that are not in 3.x.
> I heard we lack integration tests and parallel testing in 3.x is disabled.
> This does not make me feel like a GA, but starting a longer beta phase.
If we have changes in 2.x that are not in 3.x they aren’t many and we will
never find that out without releasing. In general users don’t want to use
alphas or betas. The alphas and betas are there so we can get feedback on
issues such as these but the majority of them won’t appear until a GA release.
To be clear, we MUST have one or two betas before a GA release precisely
because we WILL have issues to deal with. This is completely normal and
expected.
Lack integration tests? Yes 2.x lacks integration tests and always has. Why
would we delay 3.x for something 2.x doesn’t have. All the integration tests
will prove is that various log4j modules can coexist together because some of
them use different dependencies. The unit tests are what matter and they by and
large pass. That said, I did make the request to create integration tests
because Gary has always been afraid of breaking Log4j into multiple repos
because he believes having everything compile and build together provides
assurance that everything will work together. If everything was using managed
depdendencies that would be true. But they don’t so it isn’t.
As far as parallel testing goes, so what? That didn’t exist in 2.x until a
couple of months ago. Again, why do we need to wait. Users don’t care. The only
real consequence is that the build is slower. I put up with that for years as
release manager and, to be honest, with the newer hardware that is available
this problem to a large degree has solved itself. Not that I don’t appreciate
the builds completeing faster but that should NEVER be a requirement to delay a
release. If it had we would be one Logj4 2.4 about now.
>
>>>>> With flume, audit and the other stuff eating time, it will be hard to get
>>>>> this done.
>>>>
>>>> Get what done? As far as I am concerned Log4j 3.x can go to beta now
>>>> and GA the first of the year. There are no required features left, just
>>>> stuff that would be nice to get done but can be done after the initial
>>>> GA release.
>>>
>>> I'm talking about adding Flume to our project, adding the community, and
>>> maintaining the new component.
>>
>> Up til now that is all pretty much me. I expect it will stay that way
>> for a time, although Matt has indicated an interest in contributing.
>
> Yes, that time you don't have for 3.x
Huh? As far as I know everything I had to work on for 3.x was done prior to
alpha1. What are you talking about?
>
>>> We have open security issues with log4j-audit, and log4j-server still needs
>>> to be cleaned up.
>>
>> Log4j-Audit has no open security issues. It simply needs dependency
>> updates. Please don’t conflate one with the other.
>
> Ok, great, yes, it is using dependencies with major security holes and does
> not look maintained, yet it is promoted as a main product on our website. Did
> we check if it is OK to deliver those dependencies? Upgrading does not seem
> trivial, we haven't also even started.
WTF does this even have to do with 3.x?
>
>> Log4j-Server is a
>> sample. We don’t even release it, so I am not sure why you mention it.
>
> Because we discussed it, there was no movement because nobody seemed to have
> the time (or interest).
Discussed what? Releasing Log4j server? I recall no such discussion and would
have voted -1. That is a security nightmare I have no desire to entertain.
>
>>
>>> I am still determining how much time you can spend, but there is likely
>>> more work to be done with Log4j 3.x, and I see you are bound to Flume. I am
>>> unfamiliar with the Log4j 3 code base, but others have expressed concerns
>>> with the roadmap you proposed. Are these concerns valid? Do we need time to
>>> address them?
>>
>> Others have expressed things they would like to do because it is a
>> major release and so some end-user impact is allowable. But most, if
>> not all, of the things I have seen proposed could be done post 3.0 GA.
>> So no, it is not a requirement that they be addressed. For example,
>> Matt did a lot of work on the DI system. It took him forever. None of
>> it was required. It was/is very beneficial to do but it wasn’t required.
>
> Why do you bring up Matts work here? It seems unrelated.
Huh? Matt’s work is a HUGE part of how 3.x Is completely different than 2.x. We
have no DI system in 2.x. As I recall Matt rewrote it 3 times during the 5
years it has been under development.
>
> In one of my messages I see this issue:
>
> "Failed to execute goal
> org.apache.maven.plugins:maven-jlink-plugin:3.1.0:jlink (default-jlink) on
> project log4j-samples-jlink: "
>
> To my knowledge there is still trouble with test coverage and we could use
> some more time to make it battle field ready.
Umm. Maybe that is a problem. Maybe not. JLink isn’t even relevant to 2.x as it
isn’t fully JPMS compatible and never will be. It is OK if 3.x goes GA and not
every feature on every wishlist has been fulfilled.
To be honest, I have been getting the sense that the reluctance to release 3.x
is based largely on fear. Fear of what exactly I cannot say. I know at one
point Volkan proposed throwing 3.x away and trying to back port everything to
2.x. To even suggest that shows very little knowledge of how much work has gone
into 3.x.
When we went through the process of releasing 2.x our goad was not perfection.
I can’t be because that can NEVER be achieved. 2.x certainly is not perfect,
even with the build improvements that have been made. This software will NEVER
be done. I would think that should be obvious to everyone.
So again, I have no idea what is driving this fear. We release software, we get
feedback in the form of questions and issues and we address them. In fact,
everyone involved in Log4j 2 became involved in the project precisely because
they saw a need that needed to be filled and took it upon themselves to do it.
As an example, We could have easily not invited Volkan and JTL into Log4j but
that isn’t our way. We saw it as a way to solve existing problems and took a
chance that it would make the project better. And it has. Dragging our feet due
to fear is NOT the way forward.
Ralph
