Hi, Björn, On Wed, 13 Apr 2022 at 17:46, Björn Kautler <bjo...@kautler.net> wrote: > > I'm currently using ListAppender from log4j2-core-test, to test that > the logging of the project does what it should do. > For that I configured a ListAppender in the log4j2 config file that is > used for the tests. > In a custom global Spock extension (the test framework I use), I > retrieve the appender > using ListAppender.getListAppender and call clear() on it before an > iteration starts, > so I only get the logs written during that test and it also does not > overflow the RAM.
The main question that has not been asked in this thread is: are your loggers static or instance fields in the classes that you are testing? If it is the former (the far most common scenario), the idea of a LoggerContext per test will not work, since the logger is bound to a LoggerContext during class initialization. You can however create multiple list appenders and use RoutingAppender to select the correct one during testing: <Routing name="Routing"> <Routes pattern="$${event:ThreadId}"> <Route> <List name="${event:ThreadId}"/> </Route> </Routes> </Routing> This configuration will get you a different list appender for each thread, so your logic should work. Regarding the Log4j2 unity tests, the situation is different: the classes we test do not contain loggers, just a `StatusLogger`. While Matt's extension that provides a different logger context per test mostly solves the test concurrency problem, the tests that check the `StatusLogger` output still can not be run concurrently. Piotr --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org