June 2023 - slf4j-dev - mailman3.qos.ch

[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

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

15 Jun '23

SLF4J / SLF4J-437 [Open] Create a BOM POM ============================== 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-437 ============================== 1 comment ------------------------------ Garret Wilson on 15/Jun/23 23:32 Yes please add a BOM for SLF4J. Here are just a few libraries that offer BOMs: * Log4J * JUnit * Spring Boot Here is one more reason why the lack of a BOM is concerning. Let's say that I create a parent POM and I explicitly use {{<dependencyManagement>}} for a couple of SLF4J artifacts. Everything is fine, except that in my actual POM (the child of the other POM), I include another project, which has a transitive dependency on some other SLF4J artifact which I didn't include. Sure, all the SLF4J artifacts I put under {{<dependencyManagement>}} will override those in the transitive dependencies. But not for the other SLF4J artifacts I didn't think about. Now I have mismatched SLF4J versions in the various artifacts! Read [JAVA-307|https://globalmentor.atlassian.net/browse/JAVA-307] to see how I ran into this exact problem with JUnit. I found out JUnit now offers a BOM, though, so now I'll be set and other JUnit artifacts won't be hijacked by transitive dependencies. I've just written an in-depth article, [_Improving the Maven Bill of Materials (BOM) Pattern_|https://www.garretwilson.com/blog/2023/06/14/improve-maven-bom-pat…] which explains in detail why a BOM is needed and how to create one. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] Updates for SLF4J-591: Reference GitHub Actions by SHA and Dependency Update tool
by slf4j developers list 14 Jun '23

14 Jun '23

SLF4J / SLF4J-591 [Open] Reference GitHub Actions by SHA and Dependency Update tool ============================== 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-591 ============================== Issue created ------------------------------ Diogo Teles Sant Anna created this issue on 14/Jun/23 21:25 Summary: Reference GitHub Actions by SHA and Dependency Update tool Issue Type: Improvement Assignee: SLF4J developers list Created: 14/Jun/23 21:25 Priority: Minor Reporter: Diogo Teles Sant Anna Severity: enhancement Description: Hi! I'd like to know if you are interested in a PR to update your GitHub workflows to refer to external actions by their SHAs. This is the only way to guarantee that you're using an immutable version of the code, which might protect you from tags being moved to malicious or buggy commits. It's a recommendation from [GitHub itself|https://docs.github.com/en/actions/security-guides/security-hardenin…] and from security tools like Scorecard. Although it's more reliable and secure, a clear downsize of this change is the difficulty of maintenance, and that is why at this same Jira ticket I'd like to ask if you have considered using an Dependency Update tool, such as [Dependabot|https://github.blog/2020-06-01-keep-all-your-packages-up-to-date-with-dependabot/] or [Renovatebot|https://www.mend.io/renovate/]. Those Dependency Update tools might be useful to help manage the Java dependencies of SLF4J, but also have an an extra security impact because they would always highlight security patches from dependencies, once their available. Additionally, they're specially handy because they automatically update the SHAs of the GitHub Actions, also making sure to leave the human-readable version as a comment =) . Let me know what you think of those ideas, I'll be happy to help achieve them. h4. Additional Context I'm Diogo and I work on Google's Open Source Security Team([GOSST|https://opensource.googleblog.com/2023/04/googles-open-source-s… in cooperation with the Open Source Security Foundation ([OpenSSF|https://openssf.org/] My core job is to suggest and implement security changes on widely used open source projects 😊 ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0