SLF4J / SLF4J-592 [Open] Mechanism for indicating provider to use for unit tests.
============================== Here's what changed in this issue in the last few minutes. There is 1 comment. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-592 ============================== 1 comment ------------------------------ Garret Wilson on 21/Jun/23 22:11 Here are some extra thoughts for brainstorming. While I believe a facility to set the priority will address this use case, I think it's a bit of misuse of a priority system (although it may be the only practical solution). Normally we would use a priority system to say, "OK, I can live with that, but hey, I'd really like this other thing better." In this case, it's not that we like one or the other better, but it's that we want two different providers to be used _in different contexts_! Another approach would be to have each provider publish one or more "profile" identifiers (e.g. {{Set<String>}}). (I almost called it "context" but I don't want to confuse the concept with an in-application context, e.g. LOGBACK-1196.) Existing providers wouldn't have to change; SLF4J would consider them to be indicating no profile. If multiple providers were present on the classpath, SLF4J would no longer produce a warning; it would by default choose the one that did not indicate a profile (again providing backwards compatibility). And the existing SLF4J API would work the same when calling {{LoggerFactory.getILoggerFactory()}} and the like—it would return the provider that didn't indicate a profile. But here's the interesting part: SLF4J would provide some external method of indicating the "profile". Maybe it would be a system property. It would work conceptually similar to [Spring Boot {{spring.profiles.active}}|https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#howto.properties-and-configuration.set-active-spring-profiles]. {{LoggerFactory.bind()}} would look for this system property and if found, it would try to find and give priority to a logging provider that published its support of that profile. Again this would fall back to providers that publish support of no profiles, so existing providers would work just the same. It turns out the Maven Surefire Plugin provides a way to [set a system property for all unit tests|https://maven.apache.org/surefire/maven-surefire-plugin/examples/system-properties.html]. So with this technique, I could publish a provider that indicates it prefers the {{test}} profile. Then in the Maven Surefire Plugin I simply set the system profile to {{slf4j.profile=test}}. Suddenly all my tests will be using the provider designated for test. I'm just brainstorming here. The concept is very similar to Spring Boot active profiles, and I think it better captures what's trying to be done here. Priority sorting is a separate but complementary thing, but could be made to work. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af) _______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch https://mailman.qos.ch/cgi-bin/mailman/listinfo/slf4j-dev
