I'd like to have the PMC meet to review and discuss ScopedContext, which I am not caught up on, and whatever else we should chat about.
Gary On Fri, May 24, 2024 at 2:11 PM Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: > > Hi John, > > On Fri, 24 May 2024 at 17:17, John Engebretson <jengebr...@gmail.com> wrote: > > The long-debated ScopedContext is not significant to us. Can > > we set a target date for 2.24.0? Perhaps by punting ScopedContext to a > > later date? > > +1, the release of 2.24.0 is a blocker for: > > * the release of a performance-optimized and web-app safe > `ThreadContextMap` you contributed more than 2 months ago[1], > * the release of the next 3.0.0 beta, which will be the first without > a `log4j-api` artifact, > * a Log4j API without the LambdaMetaFactory call that makes versions > 2.19.0 to 2.23.1 unsuitable for GraalVM. > > Probably by the beginning of June (after CoCEU 2024) I can: > > 1. Move `ScopedContext` to branch 2.25.x, > 2. Replace `DefaultThreadContextMap` with the new > `StringArrayThreadContextMap`, > 3. Check if `StringArrayThreadContextMap` allows for "garbage-free > logging" (if it doesn't, it must be very close) and remove > `CopyOnWriteThreadContextMap`, > > So realistically we could expect 2.24.0 by the end of June. > > I believe that ScopedContext is a valid idea, but it still requires > some massaging. I haven't seen any performance figures yet and if the > main selling point is "you can't forget to clean up the thread > context", I am not too convinced of its utility. ThreadContext and MDC > have been around for a long time and people know how to use them > correctly. > > We should probably: > > * have a PMC meeting to brainstorm on all the selling points of > `ScopedContext`, > * do some benchmarks to see its performance, > * review all its methods so we don't repeat the errors of the past. As > I stated several times, 'ThreadContext.get()` is a mistake, because it > allows users to abuse the API and transport logging-unrelated data > through `ThreadContext`. If we could correct the past, I would remove > `ThreadContext.get()` and let `ThreadContext.put()` return the old > value. > > Piotr > > [1] https://github.com/apache/logging-log4j2/pull/2330
