For the record, I like Piotr's idea on repurposing this parameter to allow for better caching of LoggerContext in the anchor spot. This should help with some test parallelization efforts we're working on.
On Mon, Jun 6, 2022 at 1:36 AM Piotr P. Karwasz <[email protected]> wrote: > > Hi all, > > While working on test parallelisation, I was looking for the existent > mechanisms to bind a logger context to a thread. That is easily > provided by `ContextAnchor.THREAD_CONTEXT` which can be accessed by > `LogManager.getContext()/LogManager.getContext(true)`. > > However I am not sure what is the exact semantics of the > `LogManager.getContext(boolean)` call: > > * the BasicContextSelector always returns a thread-bound context, > even if the parameter is `false`, > * the ClassLoaderContextSelector only does it if called with `true` > and if no thread bound context is found it returns a default context > (which is almost certainly not what the caller wants). > > Would it be correct to modify the behavior of these selectors to: > > 1. if called with `currentContext == false` apply the selector's > logic. I believe that the `BasicContextSelector` should always return > the same context in this case, > 2. if called with `currentContext == true` return a thread bound > context and fall back to `currentContext == false` if no context is > present. This would require a modification for the > `ClassLoaderContextSelector`. > > Piotr
