now if you
> are interested.
>
> What if we are not able to pass the `Logger` instance? Judging from my
> experience, a majority of such test cases are invalid. Yet, valid ones do
> exist, at relatively few numbers. For those, I rename the test class to
> `*ForkedTest` and configu
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, J
Thanks for the quick reply, but did you actually read my last E-Mail?
I already looked at that code and had additional questions / uncertainties.
Regards
Björn
-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
F
Matt Sicker wrote:
> If you look at our LoggerContextResolver JUnit 5 extension
> code (more so in master than in release-2.x as the latter is an older
> version of the former), you'll see how you can essentially use a
> LoggerContext per test class or test instance (at least that's where
> it gets
ontextSelect for the framework you are using that keys off of
> something unique for each test to have its own ContextSelector.
>
> I know nothing about a Spock testing framework so I can’t really
> advise you there.
>
> Ralph
>
> > On Apr 13, 2022, at 5:46 PM, Björn Kautler
Hi
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 append
