I have the impression that the purpose of `currentContext` is already ambiguous and it is not clearly implemented, if not already bloated. I am not sure repurposing this would be a good idea. This said, I am far from being an expert in that area.
Piotr, thanks so much for sparing time for test parallelization. Is there anything else we can do rather than thread-local `LoggerContext`s? Can't we configure a `ContextSelector` for tests such that it will attach the `LoggerContext`s to the lifetime of a test? On Mon, Jun 6, 2022 at 8:36 AM Piotr P. Karwasz <piotr.karw...@gmail.com> 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 >
