Hi, Björn,
On Wed, 13 Apr 2022 at 17:46, Björn Kautler <[email protected]> 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: [email protected]
For additional commands, e-mail: [email protected]
