SLF4J / SLF4J-592 [Open] Programmatically specify fallback provider for unit tests.
============================== Here's what changed in this issue in the last few minutes. There are 2 comments. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-592 ============================== 2 comments ------------------------------ Garret Wilson on 21/Jun/23 19:01 {quote}Logback version 1.4.9 (unreleased as of yet) introduces a sorting mechanism for configurators.{quote} Conceptually (ignoring the configuration for the moment), that would address the use case: * The parent POM would declare {{slf4j-simple}} with a high priority, but only for {{test}} scope. * If a child project specifies a compile-time provider, it would be used normally. * If a child project specifies a compile-time provider, when running the tests {{slf4j-simple}} would be used instead because of its higher priority, but not interfere with the normal provider when not running tests. * If a child project does not specify compile-time provider, there would be no provider at all except when tests were running, in which case {{slf4j-simple}} would run That is the behavior I'm looking for (and I would imagine most users would be looking for). The snag is with configuration. I would need to configure {{slf4j-simple}} as a high priority _merely by including it in the pom with {{test}} scope_. There parent POM has no mechanism to muck with provider configuration inside {{META-INF}}. I guess the way around this is for you or me to release a {{slf4j-simple-high-priority}} artifact that already has the priority set to high, and include that artifact as {{test}} scope. But I'm still not understanding, if this sorting mechanism is specific to Logback, how it would work out if I include {{slf4j-simple-high-priority}} in the parent POM with {{test}} scope, and the child project is using Log4j as its provider. (And in fact this is exactly the scenario I'm working with; the AWS Lambda logging libraries are hard-coded to use Log4J, even though some of us are [prodding them to switch fully to SLF4J|https://github.com/aws-powertools/powertools-lambda-java/issues/965], and I'm [cajoling them to upgrade dependencies to SLF4J 2.x|https://github.com/aws-powertools/powertools-lambda-java/issues/1180] .) When I run the tests, wouldn't SLF4 still give me a warning because I have two providers on the classpath: Log4J in the main classpath, and {{slf4j-simple-high-priority}} on the test classpath? It seems to me there is no way Logback's new feature can resolve this. The sort of resolution I'm talking about has to be a part of the SLF4J provider mechanism. ------------------------------ Garret Wilson on 21/Jun/23 19:07 {quote}A test provider can have higher priority than the production provider.{quote} Yes that's basically the gist of it, with the understanding that the production provider and test provider may be different logging implementations altogether. ============================== 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
