Using the LoggerContextResolver extension, you can indeed get a
per-test LoggerContext, but without a corresponding ContextSelector
plugin to go with it, you'll have to use JUnit's parameter resolvers
to get the Logger or LoggerContext rather than using LogManager. While
that pattern works fine in our tests, that's mainly because of what
Piotr mentioned about how we log through StatusLogger in the library,
so that makes testing regular Loggers simpler here.
On Mon, Jun 6, 2022 at 12:47 AM Piotr P. Karwasz
<piotr.karw...@gmail.com> wrote:
>
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
