On Thu, Nov 2, 2023, at 08:53, Ralph Goers wrote:
>> On Nov 1, 2023, at 9:24 PM, Christian Grobmeier <c...@grobmeier.de> wrote:
>>
>>
>>
>> On Thu, Nov 2, 2023, at 02:12, Ralph Goers wrote:
>>> Christian, I was at least 3 years ahead of you on this one.This is
>>
>> Sorry I was not active for a while. Good you were here.
>>
>>> precisely why in 3.x we extracted a LOT of stuff from log4j-core into
>>> their own modules.
>>
>> Why not 2.x?
>>
>>> To be honest the main driver was JPMS - our goal for
>>> 3.x Is for log4j-core to only have a hard dependency on java.base and
>>> as few optional dependencies as possible.
>>
>> I understand, Jpms support was added to 2.x recently. Can we do the same
>> thing for 2.x?
>>
>>> So when Log4Shell hit we
>>> moved all the JNDI stuff out of log4j-core AND require a property to be
>>> set to use it even if you include the jar containing the JNDI support.
>>> In addition, JNDI can now only access the java protocol or no protocol.
>>> So yes, it is very safe now.
>>
>> In this case we need to improve our communication a lot. The main website is
>> still showing all cves and I didn’t find the information easily that I just
>> asked for.
>> As you mentioned, this issue is history for three years but the website
>> still looks like all hell is loose.
>
> The main web site is for 2.x. See https://logging.apache.org/log4j/3.x//
>
> JPMS is not the main target for 2.x as 2.x still supports Java 8 and
> has to use “versioned” jars so it can work in Java 8 and Java 11+. 3.x
> only supports Java 11 and is really where we want to focus our
> attention. I wish everyone would agree with this so we could get 3.0.0
> GA out as quickly as possible but people still want to (seemingly
> endlessly) tinker with 3.x. Once 3.x I would like to announce that
> 2.x’s EOL is directly tied to the longevity of Java 8. Once Java 8
> falls below 10% usage it will be EOL’d. So I would rather everyone
> focus their energy on 3.x and not make any more changes to 2.x other
> than bug-fixes.
So far, 3.x is super slow and as Piotr pointed out, a release might happen by
the end of 2024. we then still have many users on 2.x who will hesitate to
migrate to 3.x until it is battlefield proven. It will take years to eol 2.x
I don’t think 2.x will eol together with j8. Actually I see something different
for 2.x when it comes to jdks. Not proposing anything this is just a feeling.
>
> FWIW - this is about the 10th time I have said this. Every time people
> seem to agree but then we get the next “why can’t we add this or change
> this in 2.x”. 2.x is baked and done as far as I am concerned. To be
> honest I am almost at the point of vetoing every commit for 2.x that
> isn’t a bug fix.
This is disappointing to hear you consider your voting power to move things to
your liking. If you start doing something like this, I am out. Not that it
matters much, I assume. Reach consensus first.
We had that behavior before, don’t move down this path. You have plenty of
components that you want help with too. You don’t want these kind of veto
threats.
So far we are adding up new components while we struggle to maintain the old
ones. Some of us are concerned that the immense line of code we overlook are
too much to handle. Some of us also see that 2.x will stay a long time because
of this fact.
Retire components or move them out the main build, we can safe time that is
well invested in 3.x, Flume or Audit.
Sorry you have to repeat yourself. I see others repeat themselves too.
>
> To be clear, due to Java 8 support it was perfectly fine to leave Log4j
> 2.x as automatic modules.
>
> Ralph
