> I came to the conclusion that there is no satisfactory solution to what I
intend to do.
Lies, lies, lies.
Everything alternative facts. :-D
Ralph had a simple but brilliant idea that he mentioned in LOG4J2-1094.
I removed all the custom logic and instead now enable
Thanks so much for the elaborate investigation and taking the effort to
share your findings with us. I want to participate in this therapy session.
I learnt the hard way that one should test the logging behaviour of a
certain class. That is, the logging behaviour of subject should be a part
of
Hi
Thanks for all the hints so far.
I had some time to revisit this topic recently.
After much blood, sweat and tears (trying out many things, poking around,
rethinking things, ...),
I came to the conclusion that there is no satisfactory solution to what I
intend to do.
I'll describe in more
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
Hi, Björn,
On Wed, 13 Apr 2022 at 17:46, Björn Kautler 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
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
See
https://github.com/apache/logging-log4j2/blob/master/log4j-core-test/src/main/java/org/apache/logging/log4j/core/test/junit/LoggerContextResolver.java
for the JUnit 5 extension code. If you combine this with a ContextSelector
plugin that selects the LoggerContext based on an
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
As Ralph has indicated, the best approach would be to create a new
`LoggerContext` for each test verifying the logging behavior.
`LoggerContextRule` in the sources might be a good starting point for you.
I am actually interested in your feedback, if you happen to use it somehow.
We might consider
I'd imagine that the overhead of a LoggerContext per test would be
fairly low as long as you're not configuring hundreds of loggers in
each test. 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),
Hi Ralph
Sorry, I was distracted by other things.
> Ideally, parallel tests should use their own LoggerContext. But for the
> ClassLoaderContextSelector (the default) this would require that each
> test have its own ClassLoader. In reality it would be better to create a
> ContextSelect for the
Ideally, parallel tests should use their own LoggerContext. But for the
ClassLoaderContextSelector (the default) this would require that each
test have its own ClassLoader. In reality it would be better to create a
ContextSelect for the framework you are using that keys off of
something unique
The main reason why ListAppender doesn't support concurrent tests is
essentially a chicken-or-the-egg scenario. While I'd love to be able
to enable concurrent tests in log4j-core, for example, there are so
many tests that aren't currently configured or written to work
concurrently, nobody got
13 matches
Mail list logo
