- slf4j-dev - mailman3.qos.ch

[JIRA] Updates for SLF4J-592: Mechanism for indicating provider to use for unit tests.
by slf4j developers list 21 Jun '23

21 Jun '23

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 are 2 comments. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-592 ============================== 2 comments ------------------------------ Ceki Gülcü on 21/Jun/23 21:48 [~garretwilson] The provider ordering mechanism would be part of SLF4J. I only mentioned logback configurators as an example for inspiration. In logback 1.4.9 (experimental/unreleased), Configurator implementations declare their priority via an annotation. This annotation is part of the configurator class and cannot be altered without altering the compiled class. This approach might be more rigid than what you may have had in mind but should work assuming you create your own SLF4J providers... A custom provider can potentially consist of only a single class implementing SLF4JServiceProvider having the right order annotation and delegating to an existing implementation such as slf4j-simple. ------------------------------ Garret Wilson on 21/Jun/23 21:53 {quote}The provider ordering mechanism would be part of SLF4J. … This approach might be more rigid than what you may have had in mind but should work assuming you create your own SLF4J providers.{quote} OK that sounds workable. I don't mind publishing a simple {{stdout}} logging provider (or a version of {{slf4j-simple}}) with its priority set high. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] Updates for SLF4J-592: Mechanism for indicating provider to use for unit tests.
by slf4j developers list 21 Jun '23

21 Jun '23

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 19:30 I updated the title to better reflect the use case we're trying to address here to keep from potentially getting sidetracked focusing on one particular approach until we know it's the best solution. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] Updates for SLF4J-592: Programmatically specify fallback provider for unit tests.
by slf4j developers list 21 Jun '23

21 Jun '23

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)

1 0

[JIRA] Updates for SLF4J-592: Programmatically specify fallback provider for unit tests.
by slf4j developers list 21 Jun '23

21 Jun '23

SLF4J / SLF4J-592 [Open] Programmatically specify fallback provider 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 ------------------------------ Ceki Gülcü on 21/Jun/23 18:45 [~garretwilson] Thank you for your insightful comments. Logback version 1.4.9 (unreleased as of yet) introduces a sorting mechanism for configurators. Configurators which as the name suggests configures logback can be specified under META-INF/services/ch.qos.logback.classic.spi.Configurator. You can have multiple instances of Configurated which can be ordered and also chained. I imagine that a similar sorting/ordering mechanism can be introduced for SLF4JProviders (but without chaining providers). A test provider can have higher priority than the production provider. However, your requirement seems a bit more complicated. Let me read again. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] Updates for SLF4J-592: Programmatically specify fallback provider for unit tests.
by slf4j developers list 21 Jun '23

21 Jun '23

SLF4J / SLF4J-592 [Open] Programmatically specify fallback provider 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 17:43 The more I think about this, the more I'm inclined to think that what we really need is a way to declare a logging provider for tests that would not only serve as a fallback, it would actually _override_ the main logger if any. Because if my main application has some intricate logging defined via a Logback configuration file (e.g. logging to a file and or sending to some log aggregation service), I don't want that logger to be in effect when I run unit tests. One might say "well just define the {{slf4j-simple}} logger with scope {{test}} for your libraries, and for your application only define the application logger". There are two problems: * I'm using the same parent POM for both my libraries and my applications, and it sets {{slf4j-simple}} logger with scope {{test}}. * Even if I didn't use the same parent POM for both my libraries and my applications, there are many parts of the application I want to test for which I don't want the entire application logging configured during the running of unit tests. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] Updates for SLF4J-592: Programmatically specify fallback provider for unit tests.
by slf4j developers list 21 Jun '23

21 Jun '23

SLF4J / SLF4J-592 [Open] Programmatically specify fallback provider 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 17:32 I started thinking that the root problem here is that we need to specify a provider dependency for the runtime classpath but _not_ the test classpath. So I wondered if Gradle offered something like that; I searched and found someone asking the same thing: [Gradle dependency runtimeOnly but not in test|https://stackoverflow.com/q/74438576] There were no answers, but there was [this comment|https://stackoverflow.com/questions/74438576/gradle-dependency-runt…] {quote} A possible scenario: I would like to use {{slf4j-simple}} at runtime in my command line application, but a custom implementation of an SFL4J service provider (or logger binder in SLF4J 1.7.x) at test runtime. Since SLF4J does not like more than one service provider (or logger binder) to be present in the classpath, {{slf4j-simple}} must be excluded from the test runtime classpath. … {quote} And that's basically the ticket I opened here. 🙂 ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] Updates for SLF4J-592: Programmatically specify fallback provider for unit tests.
by slf4j developers list 21 Jun '23

21 Jun '23

SLF4J / SLF4J-592 [Open] Programmatically specify fallback provider for unit tests. ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-592 ============================== Issue created ------------------------------ Garret Wilson created this issue on 21/Jun/23 17:10 Summary: Programmatically specify fallback provider for unit tests. Issue Type: New Feature Affects Versions: 2.0.7 Assignee: SLF4J developers list Components: Core API Created: 21/Jun/23 17:10 Priority: Minor Reporter: Garret Wilson Description: I originally described this problem in [Maven exclude/remove test dependency defined in parent POM|https://stackoverflow.com/q/73747106] In {{LoggerFactory}} SLF4J automatically falls back to a do-nothing provider if no logging implementations are on the classpath. {code:java} static final NOP_FallbackServiceProvider NOP_FALLBACK_SERVICE_PROVIDER = new NOP_FallbackServiceProvider(); … List<SLF4JServiceProvider> providersList = findServiceProviders(); reportMultipleBindingAmbiguity(providersList); if (providersList != null && !providersList.isEmpty()) { PROVIDER = providersList.get(0); // SLF4JServiceProvider.initialize() is intended to be called here and nowhere else. PROVIDER.initialize(); INITIALIZATION_STATE = SUCCESSFUL_INITIALIZATION; reportActualBinding(providersList); } else { INITIALIZATION_STATE = NOP_FALLBACK_INITIALIZATION; Util.report("No SLF4J providers were found."); Util.report("Defaulting to no-operation (NOP) logger implementation"); Util.report("See " + NO_PROVIDERS_URL + " for further details."); … if (INITIALIZATION_STATE == UNINITIALIZED) { synchronized (LoggerFactory.class) { if (INITIALIZATION_STATE == UNINITIALIZED) { INITIALIZATION_STATE = ONGOING_INITIALIZATION; performInitialization(); } } } switch (INITIALIZATION_STATE) { case SUCCESSFUL_INITIALIZATION: return PROVIDER; case NOP_FALLBACK_INITIALIZATION: return NOP_FALLBACK_SERVICE_PROVIDER; {code} In a lot of libraries, I want to run unit tests and see any logging output. Thus in my libraries I would need to have a logging implementation. But a library should not be specifying a logging implementation—a library may use the SLF4J API, but leave it to some later application to specify the actual SLF4J provider. Currently in my [Maven "root" parent POM|https://github.com/globalmentor/globalmentor-root/blob/main/pom.xml] I try to sidestep this by declaring the Logback simple implementation, but only in {{test}} scope: {code:xml} <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-simple</artifactId> <scope>test</scope> </dependency> {code} This works fine except in my own applications, which use the above-mentioned root POM as their parent. One way or another they necessarily specify an SLF4J provider. As there is no way to remove the {{slf4j-simple}} provider from test scope, when I run tests for the application I get the {{SLF4J: Class path contains multiple SLF4J providers}} warning. Basically the goal here is to somehow declare a provider that only takes effect if there is no other provider present. One approach would be to enhance {{SLF4JServiceProvider}} to have something like an {{isFallback()}} method that would indicate it should only be used if no other providers are present. But this is just a degenerate case of a system of priorities, so really this would not be much different than adding a {{getPriority()}} integer or some enum of priorities. I doubt you're keen for this approach at all. Perhaps a cleaner, more surgical approach would be to add a static {{LoggerFactory.setFallbackProvider()}} method. Instead of {{static final NOP_FallbackServiceProvider NOP_FALLBACK_SERVICE_PROVIDER = new NOP_FallbackServiceProvider()}} you would have a static SLF4JServiceProvider fallbackProvider = new NOP_FallbackServiceProvider()}} internal variables. (Even the constant should have been declared to the interface {{SLF4JServiceProvider}} in the first place, in my opinion—there's no reason {{LoggerFactory}} needs to know the specific type of its fallback provider.) The new method {{LoggerFactory.setFallbackProvider()}} could check that {{INITIALIZATION_STATE == UNINITIALIZED}}, throwing an {{IllegalStateException}} if not, ensuring that this method is called before a logger is requested. Then you simply change this (and rename the enum value): {code:java} case NOP_FALLBACK_INITIALIZATION: return NOP_FALLBACK_SERVICE_PROVIDER; {code} to this: {code:java} case NOP_FALLBACK_INITIALIZATION: return fallbackProvider; {code} This should be 100% backwards compatible. It would allow any application to specify what logging implementation to use if none were provided. In my case, I could simply create a superclass for all my unit tests, and do something like: {code:java} LoggerFactory.setFallbackProvider(new MySystemOutLoggerProviderForTests()) {code} Maybe this discussion will give you an idea for an even better approach. In fact, now that I think of it, it would probably be better in a testing environment, not to provide a fallback provider, but to _force_ a provider, overriding any that is already on the main compile classpath: {code:java} LoggerFactory.forceProvider(new MySystemOutLoggerProviderForTests()) {code} You would would understandably be reluctant to allow that drastic of a change without lots of consideration. In any case, there remains a need to specify a logging provider in the context of unit tests without interfering with the main logging configuration and vice-versa. See also [Is there any simple pattern of slf4j usage in unit tests?|https://stackoverflow.com/q/3820290] (somebody else's question—I didn't write it) from 12 years ago. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] Updates for SLF4J-437: Create a BOM POM
by slf4j developers list 16 Jun '23

16 Jun '23

SLF4J / SLF4J-437 [Resolved] Create a BOM POM ============================== Here's what changed in this issue in the last few minutes. There are 2 updates. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-437 ============================== 2 updates ------------------------------ Changes by Ceki Gülcü on 16/Jun/23 18:05 Resolution: Fixed Status: Resolved (was: Open) ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] Updates for SLF4J-437: Create a BOM POM
by slf4j developers list 16 Jun '23

16 Jun '23

SLF4J / SLF4J-437 [Open] Create a BOM POM ============================== 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-437 ============================== 2 comments ------------------------------ Ceki Gülcü on 16/Jun/23 17:15 [~garretwilson] I think your Improving the Maven Bill of Materials (BOM) Pattern document is really good and vert helpful. Thank you so much. How I think I came across a very small mistake. The POM excerpt below the text "In another project, if I want to use com.example:foo and com.example.bar ...", the "foo" artifactId is referenced twice. ------------------------------ Garret Wilson on 16/Jun/23 17:23 Thanks so much for the feedback, [~ceki]. I have just now fixed the typo you mentioned. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

BOMs in Maven
by slf4j developers list 16 Jun '23

16 Jun '23

Hello all, I found Garret Wilson's documentation for "Improving the Maven Bill of Materials (BOM) Pattern" quite excellent. Here is the link: https://www.garretwilson.com/blog/2023/06/14/improve-maven-bom-pattern Best regards, -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch

1 0