- slf4j-dev - mailman3.qos.ch

[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

[JIRA] Updates for SLF4J-590: Provider artifacts still use "binding" in names and descriptions
by slf4j developers list 15 May '23

15 May '23

SLF4J / SLF4J-590 [Open] Provider artifacts still use "binding" in names and descriptions ============================== 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-590 ============================== Issue created ------------------------------ Philippe Cloutier created this issue on 15/May/23 23:14 Summary: Provider artifacts still use "binding" in names and descriptions Issue Type: Improvement Assignee: SLF4J developers list Created: 15/May/23 23:14 Priority: Trivial Reporter: Philippe Cloutier Description: SLF4J now favors the term "provider" over "binding", as can be seen in [the manual's _Linking with a logging framework at deployment time_ section|https://www.slf4j.org/manual.html#swapping] Nevertheless, multiple SLF4J artifacts still use the term "binding" instead. For example, slf4j-log4j12 and slf4j-simple. The latter has the name "SLF4J Simple Binding". ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] Updates for SLF4J-543: Improve slf4j binding diagram
by slf4j developers list 15 May '23

15 May '23

SLF4J / SLF4J-543 [Open] Improve slf4j binding diagram ============================== 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-543 ============================== 1 comment ------------------------------ Philippe Cloutier on 15/May/23 23:08 Indeed! It would also be good: * to put "unbound" next to "bound to no-operation" * to cover binding to Log4j 2 ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

Announcing investment by the Sovereign Tech Fund
by slf4j developers list 12 May '23

12 May '23

Hello all, In addition to preexisting support from companies such as Google, Exolab and Spotify R&D, we are excited to announce a sustained and multi-year investment from the Sovereign Tech Fund (STF) for the maintenance and improvement of logback, SLF4J and reload4j projects [1]. In 2006, we founded the SLF4J and logback projects and continue to maintain them until this day. Cumulatively, the artifacts of these two projects are downloaded over 4 billion times per year. Given the sheer volume of users, maintaining the SLF4J and logback projects can be rather time consuming. In 2022, we started the reload4j project with the goal of fixing critical security issues in log4j 1.x. We wish to continue providing the most reliable, fast and flexible logging framework for Java developers and heartily thank the STF for choosing to invest in our projects. The Sovereign Tech Fund supports the development, improvement and maintenance of digital infrastructure. Their goal is to sustainably strengthen the open source ecosystem, with a focus on security, resilience, technological diversity, and the people behind the projects. As Cailean Osborne aptly put it [2]: “As one of the first governmental funds dedicated to OSS, the STF is spearheading a critical shift in how governments invest in the long-term viability of OSS and digital public goods." In our own experience, even the tiniest token of support counts. It goes without saying that a larger multi-year investment counts all the more. We would like to express our gratitude to the Sovereign Tech Fund for their support and for paving the way for this historical change. [1] https://tinyurl.com/stfLogback [2] https://tinyurl.com/stfCaileanOsborne -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch

1 0

[JIRA] Updates for SLF4J-589: User manual: unclear providers list in "Binding with a logging framework at deployment time"
by slf4j developers list 04 May '23

04 May '23

SLF4J / SLF4J-589 [Resolved] User manual: unclear providers list in "Binding with a logging framework at deployment time" ============================== Here's what changed in this issue in the last few minutes. There are 2 updates, 1 comment. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-589 ============================== 2 updates ------------------------------ Changes by Ceki Gülcü on 04/May/23 23:00 Resolution: Fixed Status: Resolved (was: Open) ============================== 1 comment ------------------------------ Ceki Gülcü on 04/May/23 23:00 [~Chealer] Thank you for this report. The list is now mentioned as partial and non exhaustive. The title of the section now refers to "linking" instead of "binding" ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] Updates for SLF4J-589: User manual: unclear providers list in "Binding with a logging framework at deployment time"
by slf4j developers list 04 May '23

04 May '23

SLF4J / SLF4J-589 [Open] User manual: unclear providers list in "Binding with a logging framework at deployment time" ============================== 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-589 ============================== Issue created ------------------------------ Philippe Cloutier created this issue on 04/May/23 22:04 Summary: User manual: unclear providers list in "Binding with a logging framework at deployment time" Issue Type: Improvement Assignee: SLF4J developers list Created: 04/May/23 22:04 Priority: Minor Reporter: Philippe Cloutier Severity: normal Description: [The _Binding with a logging framework at deployment time_ section of the user manual|https://www.slf4j.org/manual.html#swapping] contains right after the first paragraph a list of ~7 providers. Unfortunately, there is no description of that list. It is unclear whether it contains a list of all providers, or just a list of some providers. It would prevent confusion to indicate which providers are listed. The current situation makes it likely readers will interpret the list as a full list of providers. If I understand correctly, this would be very problematic, as the list in fact omits major providers including those for Log4j version 2 (mainly log4j-slf4j2-impl). P.S. That section still uses the deprecated term "bindings". ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] Updates for SLF4J-588: User manual: Refers to [Apache] Commons Logging as "Jakarta Commons Logging"
by slf4j developers list 02 May '23

02 May '23

SLF4J / SLF4J-588 [Resolved] User manual: Refers to [Apache] Commons Logging as "Jakarta Commons Logging" ============================== 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-588 ============================== 2 updates ------------------------------ Changes by Ceki Gülcü on 02/May/23 22:19 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-588: User manual: Refers to [Apache] Commons Logging as "Jakarta Commons Logging"
by slf4j developers list 02 May '23

02 May '23

SLF4J / SLF4J-588 [Open] User manual: Refers to [Apache] Commons Logging as "Jakarta Commons Logging" ============================== 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-588 ============================== 1 comment ------------------------------ Ceki Gülcü on 02/May/23 20:31 [~Chealer] Thank your for this report. Given that it changing the module names would impact users, the JCL acronym is still in use. However, the documentation now mentions Apache Commons Logging as an alias for Jakarta Commons Logging. As for the missing "a", I could not find its location. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] Updates for SLF4J-588: User manual: Refers to [Apache] Commons Logging as "Jakarta Commons Logging"
by slf4j developers list 02 May '23

02 May '23

SLF4J / SLF4J-588 [Open] User manual: Refers to [Apache] Commons Logging as "Jakarta Commons Logging" ============================== 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-588 ============================== Issue created ------------------------------ Philippe Cloutier created this issue on 02/May/23 18:00 Summary: User manual: Refers to [Apache] Commons Logging as "Jakarta Commons Logging" Issue Type: Bug Assignee: SLF4J developers list Created: 02/May/23 18:00 Priority: Trivial Reporter: Philippe Cloutier Description: The user manual refers to [Commons-logging|https://commons.apache.org/proper/commons-logging/] twice in [its Binding with a logging framework at deployment time section|https://www.slf4j.org/manual.html#swapping] most importantly in its description of slf4j-jcl-2.0.7.jar: ??Binding/provider for Jakarta Commons Logging. This binding will delegate all SLF4J logging to JCL.?? While calling Commons Logging "Jakarta Commons Logging" may not be incorrect, it would be much better to call it "Apache Commons Logging", since [it was renamed|https://bugzilla.redhat.com/show_bug.cgi?id=589168] more than 13 years ago. Note that despite this rename, the previous acronym "JCL" is strangely still used, so I would suggest to keep mentioning "Jakarta Commons Logging" or at least keep the acronym. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0