Hi Volcan, On Tue, 7 Jun 2022 at 21:04, Volkan Yazıcı <vol...@yazi.ci> wrote: > 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?
>From my perspective the problem is not the `LoggerContext` itself that can be injected as a parameter in a JUnit5 test, but the `PropertiesUtil` calls used by many Log4j2 components. The `PropertiesUtil` object in release 2.x is global, so I need to use `ThreadLocal`s to replace the system properties source that is usually used. The implementation of `TestPropertySource` I provided in [1] partially works, but it fails if the test creates new threads and calls `PropertiesUtil` from there. For example HttpThreadContextMapFilterTest[2] will check if JNDI is allowed in a new thread. The most proper solution I could think of is to bind the `LoggerContext` to the thread and enhance all Log4j2 executors to propagate the current context. If I set the `LoggerContext`'s external context to JUnit5 `ExtensionContext`, I can easily implement a properties source that is restricted to the currently running test, no matter how many thread the test uses. Piotr [1] https://github.com/apache/logging-log4j2/pull/916 [2] https://github.com/apache/logging-log4j2/blob/release-2.x/log4j-core/src/test/java/org/apache/logging/log4j/core/filter/HttpThreadContextMapFilterTest.java
