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 22/Jun/23 18:17 I've filed a [ticket|https://github.com/eclipse-jdt/eclipse.jdt.core/issues/1183] for the Eclipse platform to add a facility to allow m2e to inform them of system properties derived from the POM (because apparently [this works in IntelliJ|https://youtrack.jetbrains.com/issue/IDEA-101185]), but that probably wouldn't be done for months/years, if every. Here's another idea, inspired by [this comment|https://github.com/eclipse-m2e/m2e-core/issues/174#issuecomment-1602859858]: following the [fundamental theorem|https://en.wikipedia.org/wiki/Fundamental_theorem_of_software_engineering], SLF4J could add a {{ServiceProviderNegociator}}, which is another layer of indirection in determining the provider. If a {{ServiceProviderNegociator}} is registered on the classpath (using the same service provider registration mechanism), then {{LoggerFactory.bind()}} would delegate to the {{ServiceProviderNegociator.chooseServiceProvider()}} method; otherwise it would call {{LoggerFactory.findServiceProviders()}} and use the current logic as normal. To address the test logger use case then, one would add both {{org.slf4j:slf4j-simple}} and {{org.example:provider-negociator-only-slf4j-simple}} to the parent POM, both with scope {{test}}, and things would just work. This approach allows for priorities, etc. as well, by pushing off the negotiation decision to {{ServiceProviderNegociator}}. Third parties could provide their own {{ServiceProviderNegociator}} to lookup based upon priorities or whatever. (Of course then there is the issue of choosing among multiple {{ServiceProviderNegociator}} s. 😅 Maybe you could prohibit multiple {{ServiceProviderNegociator}} s.) Adding another provider interface and an additional layer of indirection is not to be done lightly. I present it here as brainstorming if nothing else. ============================== 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
