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