Hi all, On Tue, 7 Jun 2022 at 20:22, Matt Sicker <boa...@gmail.com> wrote: > 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.
I believe this can help in more than just test parallelisation. Most frameworks I have worked with have some kind of thread bound context, e.g. Spring's `RequestContextHolder` or Vaadin's `UI.getCurrent()` and similar. These are usually propagated during async calls by the framework or the developer that makes the call. If you can create a custom context selector that uses the external thread bound context to retrieve the appropriate `LoggerContext`, async calls will go smoothly. However that is only true for the async calls that the framework/developer is aware of. Log4j2 should take care of propagating the `LoggerContext` along its internal async calls. I believe that enforcing a "get thread bound context or usual selector logic" policy on context selectors could solve this problem. As far as I can see the implications of this change would be: 1. `BasicContextSelector` called with `currentContext = false` will always give a common logger context. This is in line with what we describe in [1], while the threadlocal behavior is only documented in [2]. I think this can be considered an internal change. 2. `log4j-web` + `BasicContextSelector` could break, since `log4j-web` sets the current context and `LogManager.getContext(false)` retrieves it anyway. Piotr [1] https://logging.apache.org/log4j/2.x/manual/logsep.html [2] https://logging.apache.org/log4j/2.x/manual/extending.html
