[slf4j-dev] [JIRA] Updates for SLF4J-592: Programmatically specify fallback provider for unit tests.

[slf4j developers list]

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)