Re: [LOG4J2-3672] Time zone parsing in `FastDateParser`

[Volkan Yazıcı]

Done.

On Thu, Nov 2, 2023 at 6:58 PM Piotr P. Karwasz 
wrote:

> Hi Volkan,
>
> On Thu, 2 Nov 2023 at 18:50, Volkan Yazıcı  wrote:
> >
> > I guess the safest alternative would be to lazily initialize the
> > `FastDateFormat#parser` field.
>
> I am happy we agree on the right solution, respectful of the public
> API! Now you have my blessing to shred those unused classes to pieces.
>
> Can you also cherry-pick it to `main`?
>
> Piotr
>

Re: [Discuss]: [VOTE] Deprecation of 2.x modules/features and removal in 3.x

[Gary Gregory]

What I mean is this: When I want to work with a DB-like thing from Java, I
look 1st for a JDBC driver, when there is no FOSS option, I have to use a
DB-specifc API, for example MongoDB. Granted Cassandra is NoSQL doc store
but there are commercial JDBC drivers IIRC.

All of this to say that I feel it is nice for us to support non-JDBC stores
when there are no FOSS JDBC drivers available for that datastore type.

2. I got it backward then, thank you for explaining it again. +1 to remove
in 3.0 but keep in 2.x.

Gary

On Thu, Nov 2, 2023, 11:04 AM Ralph Goers 
wrote:

> Gary, a couple of comments:
>
> 1. I don’t understand what “there is no official JDBC access” has to do
> with Cassandra or CouchDB. Could you please elaborate?
> 2. The functionality in log4j-spring-boot is directly incorporated into
> Spring 3 due to a PR I submitted. So with Spring Boot 3 log4j-spring-boot
> should NOT be included. Since Log4j 3.x (at least in my mind) goes hand in
> hand with Spring Boot 3 then removing log4j-spring-boot in 3.x makes sense.
>
> Ralph
>
> > On Nov 2, 2023, at 7:42 AM, Gary Gregory  wrote:
> >
> > My votes:
> >
> > On Mon, Oct 30, 2023 at 4:45 AM Piotr P. Karwasz
> >  wrote:
> >>
> >> This is a vote to deprecate the following `2.x` modules and features
> >> and remove them from the `3.x` release:
> >>
> >> * `log4j-cassandra`:
> > -0: Prefer keeping since there is no official JDBC access that I know
> > of but I have not looked for a while.
> >
> >> * CouchDB appended:
> > -0: Prefer keeping since there is no official JDBC access that I know
> > of but I have not looked for a while.
> >
> >> * `log4j-docker`
> > -1 Docker seems too important.
> >
> >> * GELF appended:
> > +0
> >
> >> * Kafka appended:
> > -0: Prefer keeping since there is no official JMS access that I know
> > of but I have not looked for a while.
> >
> >> * `log4j-kubernetes`:
> > -1: This should match what we do with Docker.
> >
> >> * JeroMQ appender:
> > -0: Prefer keeping since there is no official JMS access that I know
> > of but I have not looked for a while.
> >
> >> * JNDI-related features:
> > -1: Needed in enterprise environments, OK to split out in a separate
> > Maven module.
> >
> >> * `log4j-jpa`:
> > -0: JDBC Appender is good enough for me. Use-case seems narrow except
> > for a JPA shop.
> >
> >> * Jackson based layouts (JsonLayout, XmlLayout, YamlLayout)
> > -1: I want the ability to log to XML (narrow use-case, sure, but handy).
> >
> >> * `log4j-mongodb3`:
> > +1: I use mongodb4
> >
> >> * `log4j-spring-boot`:
> > -1: Spring seems too important.
> >
> >> * Java EE SMTP appended:
> > +1: Use the Jakarta version.
> >
> >> * Jakarta EE SMTP appended:
> > -1: Handy, sometimes.
> >
> >> * `log4j-taglib`:
> > +1, never used it.
> >
> > Gary
> >
> >>
> >> Please cast votes for each module/feature separately on this mailing
> list:
> >>
> >> [ ] +1,  drop the artifact/module,
> >> [ ] +/-0
> >> [ ] -1,  keep the artifact/module, because...
> >>
> >> This vote is open for 168 hours (i.e. one week) and each deprecation
> >> will pass unless getting a net negative vote count. All votes are
> >> welcome, but only the Logging Services PMC votes are officially
> >> counted.
> >>
> >> Piotr
>
>

Re: Features for 3.x was: Why is JNDI still necessary?

[Matt Sicker]

I believe there is confusion here as to what level of compatibility 
requirements we set at the release of 3.0.0. Some remaining changes proposed 
for 3.x are technically breaking changes depending on the level of API 
stability in question. Personally, I think we should demarcate what APIs are 
truly stable public APIs and which ones are not, but we do a fairly good job of 
that with the API module itself at least (which is not where any of the 
proposed breaking changes happen to be as far as I know).

I do have experience working in codebases where backward compatibility is 
demanded above all else (Jenkins mainly, though our own API here is similar), 
so it’s not like I’m against it. However, I think it’s important to be 
realistic about what that API compatibility guarantee is, especially if you 
don’t already have some sort of stable meta-API like Linux does with system 
calls (which is itself a unique implementation detail).
—
Matt Sicker

> On Nov 2, 2023, at 21:36, Ralph Goers  wrote:
> 
> 
> 
>> On Nov 2, 2023, at 10:30 AM, Christian Grobmeier  
>> wrote:
>> 
>> 
>> 
>> On Thu, Nov 2, 2023, at 17:04, Gary Gregory wrote:
>>> Log4j 3 matching Spring 3 seems obviously a good thing to me. Going to Java
>>> 17 seems to me as well a good thing.
>>> 
>>> Gary
>>> 
>>> On Thu, Nov 2, 2023, 7:04 AM Ralph Goers  wrote:
>>> 
 I should add that I am concerned that we are missing a huge opportunity
 with Spring 3. A lot of folks will start their migration to Spring 3 early
 next year. Tying Log4J 3.x to that is a big opportunity for people to
 upgrade at the same time.
>> 
>> If this is the case, then how would we achieve the goal of releasing it 
>> together?
> 
> Releasing what together? Spring Boot 3 is already GA. It is using Log4j 2.x 
> currently. However, with Log4j 3.x targeting Java 11 and 17 (Spring Boot 3 
> requires Java 17) it will be a better choice for most users. I would also not 
> be surprised to see Spring Boot update their dependencies to use Log4j 3.x at 
> some point since they won’t require any code changes.
> 
>> 
>> 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.
> 
>> 
>> This workload is too much for this handful of people. Removing load was btw 
>> also the idea of retiring components, so we can spend this time on other 
>> things of interest
> 
> Again, I don’t know to what workload you are referring.
> 
>> 
>> I would like to suggest that we have a team call soon where we collect our 
>> ideas of how we can reach that and refresh our shared vision.
> 
> I’m pretty much always up for a team call.
> 
>> 
>> Btw what is meant with spring 3? Spring boot is 3.1.15 already, spring 
>> framework is 6.x.
> 
> Spring Boot 3.x
> 
> Ralph

Re: [Discuss]: [VOTE] Deprecation of 2.x modules/features and removal in 3.x

[Matt Sicker]

Gary, have you ever heard of JNoSQL before?  It’s 
basically a JDBC-like effort to create a generic NoSQL API. Been around for a 
few years at least, and I had considered adding an appender for this back when 
I learned about it, but I think this was by the point where I stopped making 
proof of concept appenders.
—
Matt Sicker

> On Nov 3, 2023, at 09:08, Gary Gregory  wrote:
> 
> What I mean is this: When I want to work with a DB-like thing from Java, I
> look 1st for a JDBC driver, when there is no FOSS option, I have to use a
> DB-specifc API, for example MongoDB. Granted Cassandra is NoSQL doc store
> but there are commercial JDBC drivers IIRC.
> 
> All of this to say that I feel it is nice for us to support non-JDBC stores
> when there are no FOSS JDBC drivers available for that datastore type.
> 
> 2. I got it backward then, thank you for explaining it again. +1 to remove
> in 3.0 but keep in 2.x.
> 
> Gary
> 
> On Thu, Nov 2, 2023, 11:04 AM Ralph Goers 
> wrote:
> 
>> Gary, a couple of comments:
>> 
>> 1. I don’t understand what “there is no official JDBC access” has to do
>> with Cassandra or CouchDB. Could you please elaborate?
>> 2. The functionality in log4j-spring-boot is directly incorporated into
>> Spring 3 due to a PR I submitted. So with Spring Boot 3 log4j-spring-boot
>> should NOT be included. Since Log4j 3.x (at least in my mind) goes hand in
>> hand with Spring Boot 3 then removing log4j-spring-boot in 3.x makes sense.
>> 
>> Ralph
>> 
>>> On Nov 2, 2023, at 7:42 AM, Gary Gregory  wrote:
>>> 
>>> My votes:
>>> 
>>> On Mon, Oct 30, 2023 at 4:45 AM Piotr P. Karwasz
>>>  wrote:
 
 This is a vote to deprecate the following `2.x` modules and features
 and remove them from the `3.x` release:
 
 * `log4j-cassandra`:
>>> -0: Prefer keeping since there is no official JDBC access that I know
>>> of but I have not looked for a while.
>>> 
 * CouchDB appended:
>>> -0: Prefer keeping since there is no official JDBC access that I know
>>> of but I have not looked for a while.
>>> 
 * `log4j-docker`
>>> -1 Docker seems too important.
>>> 
 * GELF appended:
>>> +0
>>> 
 * Kafka appended:
>>> -0: Prefer keeping since there is no official JMS access that I know
>>> of but I have not looked for a while.
>>> 
 * `log4j-kubernetes`:
>>> -1: This should match what we do with Docker.
>>> 
 * JeroMQ appender:
>>> -0: Prefer keeping since there is no official JMS access that I know
>>> of but I have not looked for a while.
>>> 
 * JNDI-related features:
>>> -1: Needed in enterprise environments, OK to split out in a separate
>>> Maven module.
>>> 
 * `log4j-jpa`:
>>> -0: JDBC Appender is good enough for me. Use-case seems narrow except
>>> for a JPA shop.
>>> 
 * Jackson based layouts (JsonLayout, XmlLayout, YamlLayout)
>>> -1: I want the ability to log to XML (narrow use-case, sure, but handy).
>>> 
 * `log4j-mongodb3`:
>>> +1: I use mongodb4
>>> 
 * `log4j-spring-boot`:
>>> -1: Spring seems too important.
>>> 
 * Java EE SMTP appended:
>>> +1: Use the Jakarta version.
>>> 
 * Jakarta EE SMTP appended:
>>> -1: Handy, sometimes.
>>> 
 * `log4j-taglib`:
>>> +1, never used it.
>>> 
>>> Gary
>>> 
 
 Please cast votes for each module/feature separately on this mailing
>> list:
 
 [ ] +1,  drop the artifact/module,
 [ ] +/-0
 [ ] -1,  keep the artifact/module, because...
 
 This vote is open for 168 hours (i.e. one week) and each deprecation
 will pass unless getting a net negative vote count. All votes are
 welcome, but only the Logging Services PMC votes are officially
 counted.
 
 Piotr
>> 
>> 

Re: [Discuss]: [VOTE] Deprecation of 2.x modules/features and removal in 3.x

[Gary Gregory]

Yes but I'm not sure if that's the API I found way back when I needed to
create a MongoDB appender. At the time, the projects I found was not fully
baked and I did not think there was a sensible option for a JDBC for NoSQL.

Gary

On Fri, Nov 3, 2023, 1:50 PM Matt Sicker  wrote:

> Gary, have you ever heard of JNoSQL before?  It’s
> basically a JDBC-like effort to create a generic NoSQL API. Been around for
> a few years at least, and I had considered adding an appender for this back
> when I learned about it, but I think this was by the point where I stopped
> making proof of concept appenders.
> —
> Matt Sicker
>
> > On Nov 3, 2023, at 09:08, Gary Gregory  wrote:
> >
> > What I mean is this: When I want to work with a DB-like thing from Java,
> I
> > look 1st for a JDBC driver, when there is no FOSS option, I have to use a
> > DB-specifc API, for example MongoDB. Granted Cassandra is NoSQL doc store
> > but there are commercial JDBC drivers IIRC.
> >
> > All of this to say that I feel it is nice for us to support non-JDBC
> stores
> > when there are no FOSS JDBC drivers available for that datastore type.
> >
> > 2. I got it backward then, thank you for explaining it again. +1 to
> remove
> > in 3.0 but keep in 2.x.
> >
> > Gary
> >
> > On Thu, Nov 2, 2023, 11:04 AM Ralph Goers 
> > wrote:
> >
> >> Gary, a couple of comments:
> >>
> >> 1. I don’t understand what “there is no official JDBC access” has to do
> >> with Cassandra or CouchDB. Could you please elaborate?
> >> 2. The functionality in log4j-spring-boot is directly incorporated into
> >> Spring 3 due to a PR I submitted. So with Spring Boot 3
> log4j-spring-boot
> >> should NOT be included. Since Log4j 3.x (at least in my mind) goes hand
> in
> >> hand with Spring Boot 3 then removing log4j-spring-boot in 3.x makes
> sense.
> >>
> >> Ralph
> >>
> >>> On Nov 2, 2023, at 7:42 AM, Gary Gregory 
> wrote:
> >>>
> >>> My votes:
> >>>
> >>> On Mon, Oct 30, 2023 at 4:45 AM Piotr P. Karwasz
> >>>  wrote:
> 
>  This is a vote to deprecate the following `2.x` modules and features
>  and remove them from the `3.x` release:
> 
>  * `log4j-cassandra`:
> >>> -0: Prefer keeping since there is no official JDBC access that I know
> >>> of but I have not looked for a while.
> >>>
>  * CouchDB appended:
> >>> -0: Prefer keeping since there is no official JDBC access that I know
> >>> of but I have not looked for a while.
> >>>
>  * `log4j-docker`
> >>> -1 Docker seems too important.
> >>>
>  * GELF appended:
> >>> +0
> >>>
>  * Kafka appended:
> >>> -0: Prefer keeping since there is no official JMS access that I know
> >>> of but I have not looked for a while.
> >>>
>  * `log4j-kubernetes`:
> >>> -1: This should match what we do with Docker.
> >>>
>  * JeroMQ appender:
> >>> -0: Prefer keeping since there is no official JMS access that I know
> >>> of but I have not looked for a while.
> >>>
>  * JNDI-related features:
> >>> -1: Needed in enterprise environments, OK to split out in a separate
> >>> Maven module.
> >>>
>  * `log4j-jpa`:
> >>> -0: JDBC Appender is good enough for me. Use-case seems narrow except
> >>> for a JPA shop.
> >>>
>  * Jackson based layouts (JsonLayout, XmlLayout, YamlLayout)
> >>> -1: I want the ability to log to XML (narrow use-case, sure, but
> handy).
> >>>
>  * `log4j-mongodb3`:
> >>> +1: I use mongodb4
> >>>
>  * `log4j-spring-boot`:
> >>> -1: Spring seems too important.
> >>>
>  * Java EE SMTP appended:
> >>> +1: Use the Jakarta version.
> >>>
>  * Jakarta EE SMTP appended:
> >>> -1: Handy, sometimes.
> >>>
>  * `log4j-taglib`:
> >>> +1, never used it.
> >>>
> >>> Gary
> >>>
> 
>  Please cast votes for each module/feature separately on this mailing
> >> list:
> 
>  [ ] +1,  drop the artifact/module,
>  [ ] +/-0
>  [ ] -1,  keep the artifact/module, because...
> 
>  This vote is open for 168 hours (i.e. one week) and each deprecation
>  will pass unless getting a net negative vote count. All votes are
>  welcome, but only the Logging Services PMC votes are officially
>  counted.
> 
>  Piotr
> >>
> >>
>
>

Re: Deterministic formatter

[Matt Sicker]

Alright, after looking at the differences, I’m strongly in favor of the 
Palantir version. The differences in how it handles lambdas solves one of the 
main complaints I ever had about the Google version.

> On Oct 25, 2023, at 11:47 PM, Piotr P. Karwasz  
> wrote:
> 
> Hi Matt,
> 
> On Thu, 26 Oct 2023 at 01:03, Matt Sicker  wrote:
>> 
>> Seems reasonable to me. I can’t really tell what the difference is between 
>> the two resulting outputs, though.
> 
> There was no difference (I must have used the same Spotless config
> twice), so I corrected it.
> 
> Anyway the differences are very subtle and are mainly in the wrapping 
> algorithm:
> 
> https://github.com/palantir/palantir-java-format
> 
> Piotr

[Discuss]: [VOTE] Deprecation of 2.x modules/features and removal in 3.x

[Volkan Yazıcı]

Gary, do you want to keep all Jackson modules or just XmlLayout?

-- Forwarded message -
From: Volkan Yazıcı 
Date: Thu, 2 Nov 2023 at 16:43
Subject: Re: [Discuss]: [VOTE] Deprecation of 2.x modules/features and
removal in 3.x
To: 


On Thu, Nov 2, 2023 at 4:04 PM Ralph Goers 
wrote:

> > On Nov 2, 2023, at 7:42 AM, Gary Gregory  wrote:
> > On Mon, Oct 30, 2023 at 4:45 AM Piotr P. Karwasz
> >> * Jackson based layouts (JsonLayout, XmlLayout, YamlLayout)
> > -1: I want the ability to log to XML (narrow use-case, sure, but handy).


Gary, do you only want to keep `XmlLayout` or all 3?

Re: Features for 3.x was: Why is JNDI still necessary?

[Christian Grobmeier]

On Fri, Nov 3, 2023, at 03:36, Ralph Goers wrote:
>> On Nov 2, 2023, at 10:30 AM, Christian Grobmeier  
>> wrote:
>> On Thu, Nov 2, 2023, at 17:04, Gary Gregory wrote:
>>> Log4j 3 matching Spring 3 seems obviously a good thing to me. Going to Java
>>> 17 seems to me as well a good thing.
>>> 
>>> On Thu, Nov 2, 2023, 7:04 AM Ralph Goers  wrote:
>>> 
 I should add that I am concerned that we are missing a huge opportunity
 with Spring 3. A lot of folks will start their migration to Spring 3 early
 next year. Tying Log4J 3.x to that is a big opportunity for people to
 upgrade at the same time.
>> 
>> If this is the case, then how would we achieve the goal of releasing it 
>> together?
>
> Releasing what together? Spring Boot 3 is already GA. It is using Log4j 
> 2.x currently. However, with Log4j 3.x targeting Java 11 and 17 (Spring 
> Boot 3 requires Java 17) it will be a better choice for most users. I 
> would also not be surprised to see Spring Boot update their 
> dependencies to use Log4j 3.x at some point since they won’t require 
> any code changes.

Sorry, I am a bit lost here - you spoke about Spring 3, and it sounded like it 
was something new. I understand this is nothing new. So, what exactly are we 
aiming at that justifies the "rush"? Why would a "lot of folks" upgrade to 
Spring Boot 3.16 (or whatever) next year? Why are they not doing it this year? 
Or the year after next year? Is there any special event that I missed?

>> 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. 
We have open security issues with log4j-audit, and log4j-server still needs to 
be cleaned up. 
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?

I think we can handle these tasks when we retire components more strictly. 

I am currently traveling, but when I return, I will try to set up a team 
meeting as Volkan did for Nov 12 (Sunday).

Let's try to argue in person, as email is a horrible medium.

Cheers,
Christian

Re: [Discuss]: [VOTE] Deprecation of 2.x modules/features and removal in 3.x

[Gary Gregory]

Hi Volkan,

I only care about XML.

Gary


On Fri, Nov 3, 2023, 3:27 PM Volkan Yazıcı  wrote:

> Gary, do you want to keep all Jackson modules or just XmlLayout?
>
> -- Forwarded message -
> From: Volkan Yazıcı 
> Date: Thu, 2 Nov 2023 at 16:43
> Subject: Re: [Discuss]: [VOTE] Deprecation of 2.x modules/features and
> removal in 3.x
> To: 
>
>
> On Thu, Nov 2, 2023 at 4:04 PM Ralph Goers 
> wrote:
>
>> > On Nov 2, 2023, at 7:42 AM, Gary Gregory 
>> wrote:
>> > On Mon, Oct 30, 2023 at 4:45 AM Piotr P. Karwasz
>> >> * Jackson based layouts (JsonLayout, XmlLayout, YamlLayout)
>> > -1: I want the ability to log to XML (narrow use-case, sure, but handy).
>
>
> Gary, do you only want to keep `XmlLayout` or all 3?
>

Re: Features for 3.x was: Why is JNDI still necessary?

[Ralph Goers]

> On Nov 3, 2023, at 12:47 PM, Christian Grobmeier  wrote:
> 
> On Fri, Nov 3, 2023, at 03:36, Ralph Goers wrote:
>>> On Nov 2, 2023, at 10:30 AM, Christian Grobmeier  
>>> wrote:
>>> On Thu, Nov 2, 2023, at 17:04, Gary Gregory wrote:
 Log4j 3 matching Spring 3 seems obviously a good thing to me. Going to Java
 17 seems to me as well a good thing.
 
 On Thu, Nov 2, 2023, 7:04 AM Ralph Goers  
 wrote:
 
> I should add that I am concerned that we are missing a huge opportunity
> with Spring 3. A lot of folks will start their migration to Spring 3 early
> next year. Tying Log4J 3.x to that is a big opportunity for people to
> upgrade at the same time.
>>> 
>>> If this is the case, then how would we achieve the goal of releasing it 
>>> together?
>> 
>> Releasing what together? Spring Boot 3 is already GA. It is using Log4j 
>> 2.x currently. However, with Log4j 3.x targeting Java 11 and 17 (Spring 
>> Boot 3 requires Java 17) it will be a better choice for most users. I 
>> would also not be surprised to see Spring Boot update their 
>> dependencies to use Log4j 3.x at some point since they won’t require 
>> any code changes.
> 
> Sorry, I am a bit lost here - you spoke about Spring 3, and it sounded like 
> it was something new. I understand this is nothing new. So, what exactly are 
> we aiming at that justifies the "rush"? Why would a "lot of folks" upgrade to 
> Spring Boot 3.16 (or whatever) next year? Why are they not doing it this 
> year? Or the year after next year? Is there any special event that I missed?

In the Java ecosystem almost nobody rushes to be first. Spring Boot 3 is a very 
impactful upgrade. I am currently trying to upgrade one of my services and it 
is taking a bit of time and code modification. This is because:
1. It requires Java 17
2. It changes from javax.* to jakarta.*. This is a PITA. Imports for 
annotations have to be changed. Third party libraries might have to be changed. 
For example, we use validators on our DTOs The DTOs are provided by the 
publisher. So when upgrading a consumer you now have DTOs with packages that no 
longer exist.
3. Springfox - used to generate Swagger docs - doesn’t work with Spring Boot 3 
and you have to switch to springboks - a non-trivial exercise.

I hope you get the point.

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.

> 
>>> 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.

> 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. Log4j-Server is a sample. We don’t 
even release it, so I am not sure why you mention it.

> 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.

> 
> I think we can handle these tasks when we retire components more strictly. 
> 
> I am currently traveling, but when I return, I will try to set up a team 
> meeting as Volkan did for Nov 12 (Sunday).
> 
> Let's try to argue in person, as email is a horrible medium.

I prefer not to argue, thank you. You have been around the ASF long enough to 
know that disagreements are not uncommon, if not expected. I will be the first 
to tell you that I have been upset before by being on the losing end of a 
disagreement with Gary. But I have never been upset at Gary about it - well 
except for one time I can recall for which I privately apologized to him. Each 
of us brings a unique perspective to the project and no one of us is more 
important than another - even if it were a PMC member who had only been elected 
a wee ag

Re: Features for 3.x was: Why is JNDI still necessary?

[Christian Grobmeier]

On Fri, Nov 3, 2023, at 22:28, Ralph Goers wrote:
>> On Nov 3, 2023, at 12:47 PM, Christian Grobmeier  
>> wrote:
>> Sorry, I am a bit lost here - you spoke about Spring 3, and it sounded like 
>> it was something new. I understand this is nothing new. So, what exactly are 
>> we aiming at that justifies the "rush"? Why would a "lot of folks" upgrade 
>> to Spring Boot 3.16 (or whatever) next year? Why are they not doing it this 
>> year? Or the year after next year? Is there any special event that I missed?
>
> In the Java ecosystem almost nobody rushes to be first. Spring Boot 3 
> is a very impactful upgrade. I am currently trying to upgrade one of my 
> services and it is taking a bit of time and code modification. This is 
> because:
> 1. It requires Java 17
> 2. It changes from javax.* to jakarta.*. This is a PITA. Imports for 
> annotations have to be changed. Third party libraries might have to be 
> changed. For example, we use validators on our DTOs The DTOs are 
> provided by the publisher. So when upgrading a consumer you now have 
> DTOs with packages that no longer exist.
> 3. Springfox - used to generate Swagger docs - doesn’t work with Spring 
> Boot 3 and you have to switch to springboks - a non-trivial exercise.

I know upgrading from Spring Boot 2.5 to Spring Boot 3.1.x is non-trivial since 
I do a lot of Spring, too, but I don't understand why you assume everybody 
starts upgrading next year.

> 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. 

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.

 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

>> 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.

> 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).

>
>> 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. 

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. 

>> Let's try to argue in person, as email is a horrible medium.
>
> I prefer not to argue, thank you. You have been around the ASF long 
> enough to know that disagreements are not uncommon, if not expected. 

I am sorry, please consider language: I looked up the difference between argue 
and discussion. I meant "discuss". Argue in my language has a different 
feeling. And yes, I have been around long enough, I know.