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
