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 ExtensionContext.Store, then you can parallelize things pretty efficiently.
— Matt Sicker > On Jun 5, 2022, at 20:14, Björn Kautler <bjo...@kautler.net> wrote: > > 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 stored for this extension). > > I had a look and I could probably port that over to a Spock extension > fairly easily. > And opposed to the `LoggerContextRule` it also seems not to use static > state or system properties. > But from looking at the code I don't see how this is logger context > then is used by the SUT code. > > Matt Sicker wrote: >> The other side of things would be >> making a ContextSelector implementation for log4j-core that could >> select the LoggerContext to use based on the JUnit ExtensionStore. > > Is this the part that would make the `LoggerContext` from the > extension be used by the SUT code? > How would it access the extension store in that situation? > How does it work with the JUnit 5 extension currently then, because I > see no such context selector? > Or what is the part I'm missing right now? > > Matt Sicker wrote: >> The implementation details are a bit fuzzy, but there's already logic in >> LoggerContextResolver to check the test instance for @Factory-style >> methods (similar to @Bean methods in Spring) for dependency injection setup, > > Not sure what you mean, the only thing I see is that it searches for > `LoggerContextSource` annotations on the class and test method. > > Volkan Yazıcı wrote: >> `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. > > My feedback for this is already in the original post here. > Let met quote myself: >> I looked into the LoggerContextRule whether I find something useful there, >> but - please correct me if I'm wrong - as far as I have seen it also >> is not capable of parallel execution >> as it uses system properties and static state, so parallel tests would >> also overwrite each other I guess. > > Volkan Yazıcı wrote: >> I would refrain from patching `ListAppender` using `ThreadLocal`s. There >> might be other components which are subject to misbehaviour when accessed >> concurrently. > > You think log4j is not thread-safe? > Or how should this statement be interpreted? > > Volkan Yazıcı wrote: >> Hence you better give each of your tests a pristine `LoggerContext`. > > If I finally understand how, I might do it like that. :-) > > --------------------------------------------------------------------- > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-user-h...@logging.apache.org >
