I would think we would want to use some sort of JunitContextSelector and modify PropertiesUtil so that JUnit can provide the SystemProperties.
You do not want to point the external context to JUnit’s ExtensionContext. Instead, you should add it as a key to the externalMap. Ralph > On Jun 7, 2022, at 12:27 PM, Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: > > 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
