> On Nov 3, 2023, at 12:47 PM, Christian Grobmeier <grobme...@apache.org> wrote:
>
> On Fri, Nov 3, 2023, at 03:36, Ralph Goers wrote:
>>> On Nov 2, 2023, at 10:30 AM, Christian Grobmeier <grobme...@apache.org>
>>> 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 <ralph.go...@dslextreme.com>
>>>> 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 ago.
Piotr did the correct thing. He created a vote thread and let everyone vote.
Once the vote is tallied we accept the results and move on, even if we are not
completely happy with the result. I can guarantee it will not be the last vote
of its type we hold.
Ralph
