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
