On Fri, Nov 3, 2023, at 22:28, Ralph Goers wrote: >> On Nov 3, 2023, at 12:47 PM, Christian Grobmeier <grobme...@apache.org> >> 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.
