From noreply-jira at qos.ch Mon Mar 13 15:44:00 2023 From: noreply-jira at qos.ch (QOS.CH (JIRA)) Date: Mon, 13 Mar 2023 15:44:00 +0100 (CET) Subject: [slf4j-dev] [JIRA] Updates for SLF4J-576: Mailman hits bug when trying to subscribe to slf4j-user mailing list In-Reply-To: References: Message-ID: SLF4J / SLF4J-576 [Open] Mailman hits bug when trying to subscribe to slf4j-user mailing list ============================== Here's what changed in this issue in the last few minutes. This issue has been created There is 1 comment. This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-576 ============================== Issue created ------------------------------ Sebastian Kürten created this issue on 13/Mar/23 3:33 PM Summary: Mailman hits bug when trying to subscribe to slf4j-user mailing list Issue Type: Bug Assignee: SLF4J developers list Components: Unspecified Created: 13/Mar/23 3:33 PM Priority: Major Reporter: Sebastian Kürten Description: I'm trying to sign up here: [https://mailman.qos.ch/mailman/listinfo/slf4j-user] and am getting this error message: h2. Bug in Mailman version 2.1.20 h3. We're sorry, we hit a bug! Please inform the webmaster for this site of this problem. Printing of traceback and other system information has been explicitly inhibited, but the webmaster can find this information in the Mailman error logs. ============================== 1 comment ------------------------------ Sebastian Kürten on 13/Mar/23 3:34 PM I realize this is not an issue with the source code or anything, but it's still related to the project, so it seemed reasonable to report it here. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af) From noreply-jira at qos.ch Mon Mar 13 16:00:00 2023 From: noreply-jira at qos.ch (QOS.CH (JIRA)) Date: Mon, 13 Mar 2023 16:00:00 +0100 (CET) Subject: [slf4j-dev] [JIRA] Updates for SLF4J-576: Mailman hits bug when trying to subscribe to slf4j-user mailing list In-Reply-To: References: Message-ID: SLF4J / SLF4J-576 [Resolved] Mailman hits bug when trying to subscribe to slf4j-user mailing list ============================== 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-576 ============================== 2 updates ------------------------------ Changes by Ceki Gülcü on 13/Mar/23 3:49 PM Resolution: Fixed Status: Resolved (was: Open) ============================== 1 comment ------------------------------ Ceki Gülcü on 13/Mar/23 3:49 PM [~sebkur] Thank you for this report. This issue has been solved now. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af) From noreply-jira at qos.ch Mon Mar 13 17:13:00 2023 From: noreply-jira at qos.ch (QOS.CH (JIRA)) Date: Mon, 13 Mar 2023 17:13:00 +0100 (CET) Subject: [slf4j-dev] [JIRA] Updates for SLF4J-576: Mailman hits bug when trying to subscribe to slf4j-user mailing list In-Reply-To: References: Message-ID: SLF4J / SLF4J-576 [Closed] Mailman hits bug when trying to subscribe to slf4j-user mailing list ============================== 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-576 ============================== 1 comment ------------------------------ Sebastian Kürten on 13/Mar/23 4:52 PM Thanks! ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af) From noreply-jira at qos.ch Tue Mar 14 11:15:00 2023 From: noreply-jira at qos.ch (QOS.CH (JIRA)) Date: Tue, 14 Mar 2023 11:15:00 +0100 (CET) Subject: [slf4j-dev] [JIRA] Updates for SLF4J-576: Mailman hits bug when trying to subscribe to slf4j-user mailing list In-Reply-To: References: Message-ID: SLF4J / SLF4J-576 Mailman hits bug when trying to subscribe to slf4j-user mailing list ============================== Here's what changed in this issue in the last few minutes. This issue has been deleted ============================== Issue deleted ------------------------------ Ceki Gülcü has deleted this issue on 14/Mar/23 11:04 AM ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af) From noreply-jira at qos.ch Tue Mar 14 11:15:00 2023 From: noreply-jira at qos.ch (QOS.CH (JIRA)) Date: Tue, 14 Mar 2023 11:15:00 +0100 (CET) Subject: [slf4j-dev] [JIRA] Updates for SLF4J-577: Export slf4j packages in version 1 and 2 in OSGi-Manifests In-Reply-To: References: Message-ID: SLF4J / SLF4J-577 [Open] Export slf4j packages in version 1 and 2 in OSGi-Manifests ============================== 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-577 ============================== Issue created ------------------------------ Ceki Gülcü created this issue on 14/Mar/23 11:06 AM Summary: Export slf4j packages in version 1 and 2 in OSGi-Manifests Issue Type: Bug Assignee: SLF4J developers list Created: 14/Mar/23 11:05 AM Environment: Priority: Major Reporter: Ceki Gülcü Description: Hannes Wellmann on 16/Dec/22 3:24 PM Issue https://jira.qos.ch/browse/SLF4J-577 turned out to be a false alarm. However this made me think about this issue a bit more and actually only the packages that are relevant for clients should be exported in a version 1.x. The package-info for {{org.slf4j.spi}} states that this package should not be used by clients. @ceki can you clarify if anything from {{org.slf4j.helpers}} respectivly {{org.slf4j.event}} were relevant for clients in{{ SLF4J-1?}} If there is nothing it should not be necessary they should not be exported in version 1 as well. This would also solve the problem that a SLF4J-1 binding would have been wired to the slf4j-api in version 2, but if they e.g. import {{org.slf4j.spi}} in version 1 it can only be wired to slf4j-api in version 1. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af) From noreply-jira at qos.ch Tue Mar 14 11:15:00 2023 From: noreply-jira at qos.ch (QOS.CH (JIRA)) Date: Tue, 14 Mar 2023 11:15:00 +0100 (CET) Subject: [slf4j-dev] [JIRA] Updates for SLF4J-578: Restore full binary compatibility and add baseline-tooling to enforce it in the future In-Reply-To: References: Message-ID: SLF4J / SLF4J-578 [Open] Restore full binary compatibility and add baseline-tooling to enforce it in the future ============================== Here's what changed in this issue in the last few minutes. This issue has been created There are 2 comments. This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-578 ============================== Issue created ------------------------------ Ceki Gülcü created this issue on 14/Mar/23 11:09 AM Summary: Restore full binary compatibility and add baseline-tooling to enforce it in the future Issue Type: Bug Assignee: SLF4J developers list Created: 14/Mar/23 11:09 AM Priority: Major Reporter: Ceki Gülcü Description: Reporter: Hannes Wellmann The documentation claims that SLF4-2 is binary compatible to slf4j-1, from a client perspective: * [https://www.slf4j.org/faq.html#compatibility] * [https://www.slf4j.org/faq.html#changesInVersion200] But for example [LoggingEvent.getMarker() in [slf4j-1.7|https://github.com/qos-ch/slf4j/blob/e9ee55cca93c2bf26f14482a9bdf961c750d2a56/slf4j-api/src/main/java/org/slf4j/event/LoggingEvent.java#L14] was changed to [LoggingEvent.getMarkers() in slf4j-2|https://github.com/qos-ch/slf4j/blob/f85104040ce44ac545e15e4f41ef771a7a7f7add/slf4j-api/src/main/java/org/slf4j/event/LoggingEvent.java#L26] and now returns a List of Markers instead of a single Marker. This looks like a binary incompatible change to me. Would it be possible to restore the old {{getMarker()}} method as deprecated, in order to restore the binary compatibility? If you are interested, to avoid such changes in the future the [bnd-baseline-maven-plugin could help to avoid such change. |https://github.com/bndtools/bnd/tree/master/maven-plugins/bnd-baseline-maven-plugin]But I would have to find out first, if it is possible to perform the check like if the major version was not increment and thus removals are forbidden. Maybe this will also find other binary incompatible changes. ============================== 2 comments ------------------------------ Ceki Gülcü on 14/Mar/23 11:13 AM Ceki Gülcü on 15/Dec/22 8:33 PM [~HannesWell] In version 1.7, LoggingEvent was used internally and in 2.0.0 it is intended for use by implementations via the fluent API. ------------------------------ Ceki Gülcü on 14/Mar/23 11:14 AM Hannes Wellmann on 16/Dec/22 3:05 PM Thanks for the clearification and the false alarm. Nevertheless are you interested in having some tooling support in the build to ensure binary compatibility? ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af) From noreply-jira at qos.ch Tue Mar 14 11:28:00 2023 From: noreply-jira at qos.ch (QOS.CH (JIRA)) Date: Tue, 14 Mar 2023 11:28:00 +0100 (CET) Subject: [slf4j-dev] [JIRA] Updates for SLF4J-579: Export slf4j packages in version 1 and 2 in OSGi-Manifests In-Reply-To: References: Message-ID: SLF4J / SLF4J-579 [Open] Export slf4j packages in version 1 and 2 in OSGi-Manifests ============================== 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-579 ============================== Issue created ------------------------------ Ceki Gülcü created this issue on 14/Mar/23 11:17 AM Summary: Export slf4j packages in version 1 and 2 in OSGi-Manifests Issue Type: Bug Assignee: SLF4J developers list Created: 14/Mar/23 11:17 AM Priority: Major Reporter: Ceki Gülcü Description: Components: Core API Created: 14/Dec/22 11:11 PM Environment: The documentation claims that SLF4J-2 is binary compatible to slf4j-1, from a client perspective: * [https://www.slf4j.org/faq.html#compatibility] * [https://www.slf4j.org/faq.html#changesInVersion200] In order to ease migration to slf4j-2 in the OSGi world and to allow the usage of libraries that are build against slf4j-1 and therefore have a Import-Package version range with exclusive upper-bound of 2 in an OSGi runtime that has SLF4J-2 installed it would be beneficial if slf4j-api would export its packages in version 1 (probably the latest one) and two. Eventually the Manifest of slf4j-api would have an entry like the following (plus uses-constraints): {code:java} Export-Package: org.slf4j;version="1.7.36", org.slf4j;version="2.0.7", org.slf4j.event;version="1.7.36", org.slf4j.event;version="2.0.7", org.slf4j.helpers;version="1.7.36", org.slf4j.helpers;version="2.0.7" org.slf4j.spi;version="1.7.36", org.slf4j.spi;version="2.0.7" {code} ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af) From noreply-jira at qos.ch Tue Mar 14 11:40:00 2023 From: noreply-jira at qos.ch (QOS.CH (JIRA)) Date: Tue, 14 Mar 2023 11:40:00 +0100 (CET) Subject: [slf4j-dev] [JIRA] Updates for SLF4J-579: Export slf4j packages in version 1 and 2 in OSGi-Manifests In-Reply-To: References: Message-ID: SLF4J / SLF4J-579 [Open] Export slf4j packages in version 1 and 2 in OSGi-Manifests ============================== Here's what changed in this issue in the last few minutes. There are 3 comments. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-579 ============================== 3 comments ------------------------------ Ceki Gülcü on 14/Mar/23 11:29 AM Ceki Gülcü on 15/Dec/22 8:33 PM [~HannesWell] In version 1.7, LoggingEvent was used internally and in 2.0.0 it is intended for use by implementations via the fluent API. ------------------------------ Ceki Gülcü on 14/Mar/23 11:29 AM Hannes Wellmann on 16/Dec/22 3:05 PM Thanks for the clearification and the false alarm. Nevertheless are you interested in having some tooling support in the build to ensure binary compatibility? ------------------------------ Ceki Gülcü on 14/Mar/23 11:30 AM Hannes Wellmann on 16/Dec/22 3:24 PM Issue https://jira.qos.ch/browse/SLF4J-578 turned out to be a false alarm. However this made me think about this issue a bit more and actually only the packages that are relevant for clients should be exported in a version 1.x. The package-info for {{org.slf4j.spi}} states that this package should not be used by clients. @ceki can you clarify if anything from {{org.slf4j.helpers}} respectivly {{org.slf4j.event}} were relevant for clients in{{ SLF4J-1?}} If there is nothing it should not be necessary they should not be exported in version 1 as well. This would also solve the problem that a SLF4J-1 binding would have been wired to the slf4j-api in version 2, but if they e.g. import {{org.slf4j.spi}} in version 1 it can only be wired to slf4j-api in version 1. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af) From noreply-jira at qos.ch Tue Mar 14 11:51:00 2023 From: noreply-jira at qos.ch (QOS.CH (JIRA)) Date: Tue, 14 Mar 2023 11:51:00 +0100 (CET) Subject: [slf4j-dev] [JIRA] Updates for SLF4J-580: OSGi: jcl-over-slf4j does not export org.apache.commons.logging.impl In-Reply-To: References: Message-ID: SLF4J / SLF4J-580 [Open] OSGi: jcl-over-slf4j does not export org.apache.commons.logging.impl ============================== 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-580 ============================== Issue created ------------------------------ Ceki Gülcü created this issue on 14/Mar/23 11:40 AM Summary: OSGi: jcl-over-slf4j does not export org.apache.commons.logging.impl Issue Type: Bug Assignee: SLF4J developers list Created: 14/Mar/23 11:40 AM Priority: Major Reporter: Ceki Gülcü Description: Created: 19/Dec/22 4:40 PM Reporter: Dr. Domagoj Ćosić jcl-over-slf4j did export {{org.apache.commons.logging.impl}} in all previous versions. In release 2.0.6, it does not. I cannot imagine that this is a conscious API change. Expected behavior: all contained packages as also exported in {{Export-Package}}. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af) From noreply-jira at qos.ch Wed Mar 15 20:34:00 2023 From: noreply-jira at qos.ch (QOS.CH (JIRA)) Date: Wed, 15 Mar 2023 20:34:00 +0100 (CET) Subject: [slf4j-dev] [JIRA] Updates for SLF4J-577: Restore full binary compatibility and add baseline-tooling In-Reply-To: References: Message-ID: SLF4J / SLF4J-577 [Open] Restore full binary compatibility and add baseline-tooling ============================== 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-577 ============================== 2 comments ------------------------------ Ceki Gülcü on 15/Mar/23 20:22 Ceki Gülcü on 15/Dec/22 8:33 PM [~HannesWell] In version 1.7, LoggingEvent was used internally and in 2.0.0 it is intended for use by implementations via the fluent API. So, close but no cigar. ------------------------------ Ceki Gülcü on 15/Mar/23 20:23 Hannes Wellmann on 16/Dec/22 3:05 PM Thanks for the clearification and the false alarm. Nevertheless are you interested in having some tooling support in the build to ensure binary compatibility? ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af) From noreply-jira at qos.ch Wed Mar 15 21:00:00 2023 From: noreply-jira at qos.ch (QOS.CH (JIRA)) Date: Wed, 15 Mar 2023 21:00:00 +0100 (CET) Subject: [slf4j-dev] [JIRA] Updates for SLF4J-580: OSGi: jcl-over-slf4j does not export org.apache.commons.logging.impl In-Reply-To: References: Message-ID: SLF4J / SLF4J-580 [Open] OSGi: jcl-over-slf4j does not export org.apache.commons.logging.impl ============================== 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-580 ============================== 1 comment ------------------------------ Ceki Gülcü on 15/Mar/23 20:48 I can confirm this bug. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af) From slf4j-dev at qos.ch Thu Mar 16 18:10:00 2023 From: slf4j-dev at qos.ch (slf4j developers list) Date: Thu, 16 Mar 2023 18:10:00 +0100 (CET) Subject: [slf4j-dev] [JIRA] Updates for SLF4J-581: Fully automate OSGi metadata creation and fix broken OSGi-metadata in slf4j-api In-Reply-To: References: Message-ID: SLF4J / SLF4J-581 [Open] Fully automate OSGi metadata creation and fix broken OSGi-metadata in slf4j-api ============================== 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-581 ============================== Issue created ------------------------------ Ceki Gülcü created this issue on 16/Mar/23 18:00 Summary: Fully automate OSGi metadata creation and fix broken OSGi-metadata in slf4j-api Issue Type: Improvement Assignee: SLF4J developers list Created: 16/Mar/23 18:00 Priority: Major Reporter: Ceki Gülcü ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af) From slf4j-dev at qos.ch Thu Mar 16 18:10:00 2023 From: slf4j-dev at qos.ch (slf4j developers list) Date: Thu, 16 Mar 2023 18:10:00 +0100 (CET) Subject: [slf4j-dev] [JIRA] Updates for SLF4J-578: OSGi: jcl-over-slf4j does not export org.apache.commons.logging.impl In-Reply-To: References: Message-ID: SLF4J / SLF4J-578 [In Progress] OSGi: jcl-over-slf4j does not export org.apache.commons.logging.impl ============================== 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-578 ============================== 1 comment ------------------------------ Ceki Gülcü on 16/Mar/23 17:59 [~domagoj] I can confirm this issue. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af) From slf4j-dev at qos.ch Thu Mar 16 18:10:00 2023 From: slf4j-dev at qos.ch (slf4j developers list) Date: Thu, 16 Mar 2023 18:10:00 +0100 (CET) Subject: [slf4j-dev] [JIRA] Updates for SLF4J-580: DUPLICATE: OSGi: jcl-over-slf4j does not export org.apache.commons.logging.impl In-Reply-To: References: Message-ID: SLF4J / SLF4J-580 [Resolved] DUPLICATE: OSGi: jcl-over-slf4j does not export org.apache.commons.logging.impl ============================== 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-580 ============================== 2 updates ------------------------------ Changes by Ceki Gülcü on 16/Mar/23 17:58 Resolution: Duplicate Status: Resolved (was: In Progress) ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af) From slf4j-dev at qos.ch Thu Mar 16 18:40:00 2023 From: slf4j-dev at qos.ch (slf4j developers list) Date: Thu, 16 Mar 2023 18:40:00 +0100 (CET) Subject: [slf4j-dev] [JIRA] Updates for SLF4J-582: Add license file to Jar In-Reply-To: References: Message-ID: SLF4J / SLF4J-582 [Open] Add license file to Jar ============================== 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-582 ============================== Issue created ------------------------------ Ceki Gülcü created this issue on 16/Mar/23 18:28 Summary: Add license file to Jar Issue Type: Improvement Affects Versions: 2.0.6 Assignee: SLF4J developers list Created: 16/Mar/23 18:28 Fix Versions: 2.0.7 Priority: Major Reporter: Ceki Gülcü Description: Tobias Wittmann created this issue on 25/Jan/23 10:51 AM For a customer project an OpenSource report has to be generated. Therefore a scanner was created to extract the licence information from our dependencies. This scanner can extract all informaton from the Jar file. Therefore it would be great to have the license information included in the Jar file as LICENSE.txt file. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af) From slf4j-dev at qos.ch Fri Mar 17 08:22:00 2023 From: slf4j-dev at qos.ch (slf4j developers list) Date: Fri, 17 Mar 2023 08:22:00 +0100 (CET) Subject: [slf4j-dev] [JIRA] Updates for SLF4J-583: incorrect require-bundle in slf4j-simple to slf4j-api since 2.0.6 In-Reply-To: References: Message-ID: SLF4J / SLF4J-583 [Open] incorrect require-bundle in slf4j-simple to slf4j-api since 2.0.6 ============================== 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-583 ============================== Issue created ------------------------------ Ceki Gülcü created this issue on 17/Mar/23 8:10 Summary: incorrect require-bundle in slf4j-simple to slf4j-api since 2.0.6 Issue Type: Bug Assignee: SLF4J developers list Created: 17/Mar/23 8:10 Priority: Blocker Reporter: Ceki Gülcü Description: Since 2.0.6 the symbolic names are changed in SLF4J which introduced an inconsistency which creates a problem within OSGi environments slf4j-simple MANIFEST contains this {{}} {code:java} Require-Bundle: slf4j.api {code} while at the same time slf4j-api MANIFEST contains this {{}} {code:java} Bundle-SymbolicName: org.slf4j.api\{code} {{}} *reproduction:* download slf4j-simple and slf4j-api from mvncentral and inspect the manifest in the jars As far as I can tell at this moment it is since the maven-bundle-plugin is used which might be incorrectly configured. It is also weird that there is already a manifest.mf file in the sourcecode which does not seem to be used but overwritten by the maven-bundle-plugin as in manifest.mf files in the source the symbolic bundle names have not changed. Sidenote: all symbolic bundle names have changed which is anyhow a change which results in a lot of work in OSGi based projects as all manifest.mf files need to be adjusted. I have a feeling this was an unwanted change? ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af) From slf4j-dev at qos.ch Fri Mar 17 18:32:00 2023 From: slf4j-dev at qos.ch (slf4j developers list) Date: Fri, 17 Mar 2023 18:32:00 +0100 (CET) Subject: [slf4j-dev] [JIRA] Updates for SLF4J-579: Export slf4j packages in version 1 and 2 in OSGi-Manifests In-Reply-To: References: Message-ID: SLF4J / SLF4J-579 [Resolved] Export slf4j packages in version 1 and 2 in OSGi-Manifests ============================== 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-579 ============================== 2 updates ------------------------------ Changes by Ceki Gülcü on 17/Mar/23 18:20 Resolution: Fixed Status: Resolved (was: In Progress) ============================== 1 comment ------------------------------ Ceki Gülcü on 17/Mar/23 18:23 After some discussion, it was agreed to export {{slf4j-api}} as both versions 2.0.x and 1.7.x and other packages as version 2.0.x only. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af) From slf4j-dev at qos.ch Fri Mar 17 19:36:00 2023 From: slf4j-dev at qos.ch (slf4j developers list) Date: Fri, 17 Mar 2023 19:36:00 +0100 (CET) Subject: [slf4j-dev] [JIRA] Updates for SLF4J-583: incorrect require-bundle in slf4j-simple to slf4j-api since 2.0.6 In-Reply-To: References: Message-ID: SLF4J / SLF4J-583 [Resolved] incorrect require-bundle in slf4j-simple to slf4j-api since 2.0.6 ============================== 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-583 ============================== 2 updates ------------------------------ Changes by Ceki Gülcü on 17/Mar/23 19:24 Resolution: Fixed Status: Resolved (was: Open) ============================== 1 comment ------------------------------ Ceki Gülcü on 17/Mar/23 19:24 With the latest changes in SLF4J-581 and SLF4J-578. This issue is deemed solved, ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af) From slf4j-dev at qos.ch Fri Mar 17 19:48:00 2023 From: slf4j-dev at qos.ch (slf4j developers list) Date: Fri, 17 Mar 2023 19:48:00 +0100 (CET) Subject: [slf4j-dev] [JIRA] Updates for SLF4J-581: Fully automate OSGi metadata creation and fix broken OSGi-metadata in slf4j-api In-Reply-To: References: Message-ID: SLF4J / SLF4J-581 [Resolved] Fully automate OSGi metadata creation and fix broken OSGi-metadata in slf4j-api ============================== 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-581 ============================== 2 updates ------------------------------ Changes by Ceki Gülcü on 17/Mar/23 19:37 Resolution: Fixed Status: Resolved (was: Open) ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af) From slf4j-dev at qos.ch Fri Mar 17 19:48:00 2023 From: slf4j-dev at qos.ch (slf4j developers list) Date: Fri, 17 Mar 2023 19:48:00 +0100 (CET) Subject: [slf4j-dev] [JIRA] Updates for SLF4J-582: Add license file to Jar In-Reply-To: References: Message-ID: SLF4J / SLF4J-582 [Resolved] Add license file to Jar ============================== 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-582 ============================== 2 updates ------------------------------ Changes by Ceki Gülcü on 17/Mar/23 19:36 Resolution: Fixed Status: Resolved (was: Open) ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af) From slf4j-dev at qos.ch Fri Mar 17 19:48:00 2023 From: slf4j-dev at qos.ch (slf4j developers list) Date: Fri, 17 Mar 2023 19:48:00 +0100 (CET) Subject: [slf4j-dev] [JIRA] Updates for SLF4J-584: slf4j-api has no javadocs In-Reply-To: References: Message-ID: SLF4J / SLF4J-584 [Open] slf4j-api has no javadocs ============================== Here's what changed in this issue in the last few minutes. This issue has been created View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-584 ============================== Issue created ------------------------------ Ceki Gülcü created this issue on 17/Mar/23 19:45 Summary: slf4j-api has no javadocs Issue Type: Bug Assignee: Ceki Gülcü Created: 17/Mar/23 19:45 Priority: Major Reporter: Ceki Gülcü Description: Witalij Berdinskich created this issue on 07/Feb/23 12:31 PM The [javadocs has been published|https://repo1.maven.org/maven2/org/slf4j/slf4j-api/2.0.6/] but the jar contains sources only. The version 2.0.3 has correct javadocs. It's not a critical issue, on my opinion. But any dependent project could not build its own javadocs if it refers on slf4j-api's javadoc. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af) From slf4j-dev at qos.ch Fri Mar 17 20:55:00 2023 From: slf4j-dev at qos.ch (slf4j developers list) Date: Fri, 17 Mar 2023 20:55:00 +0100 (CET) Subject: [slf4j-dev] [JIRA] Updates for SLF4J-584: slf4j-api has no javadocs In-Reply-To: References: Message-ID: SLF4J / SLF4J-584 [Resolved] slf4j-api has no javadocs ============================== 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-584 ============================== 2 updates ------------------------------ Changes by Ceki Gülcü on 17/Mar/23 20:43 Resolution: Fixed Status: Resolved (was: In Progress) ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af) From slf4j-dev at qos.ch Fri Mar 17 22:35:00 2023 From: slf4j-dev at qos.ch (slf4j developers list) Date: Fri, 17 Mar 2023 22:35:00 +0100 (CET) Subject: [slf4j-dev] [JIRA] Updates for SLF4J-579: Export slf4j packages in version 1 and 2 in OSGi-Manifests In-Reply-To: References: Message-ID: SLF4J / SLF4J-579 [Resolved] Export slf4j packages in version 1 and 2 in OSGi-Manifests ============================== 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-579 ============================== 1 comment ------------------------------ Hannes Wellmann on 17/Mar/23 22:23 > After some discussion, it was agreed to export {{slf4j-api}} as both versions 2.0.x and 1.7.x and other packages as version 2.0.x only. I would like to make it more clear that the {{slf4j-api}} bundle (Bundle-SymbolicName: {{{}slf4j.api{}}}) only exports the package {{org.slf4j}} in version 2.0.x and 1.7.x. All of its other packages, which are considered only relevant for logging-backends, are exported in version 2.0.x only. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af) From slf4j-dev at qos.ch Mon Mar 20 21:09:00 2023 From: slf4j-dev at qos.ch (slf4j developers list) Date: Mon, 20 Mar 2023 21:09:00 +0100 (CET) Subject: [slf4j-dev] [JIRA] Updates for SLF4J-585: Broken link on website (SimpleLogger) In-Reply-To: References: Message-ID: SLF4J / SLF4J-585 [Open] Broken link on website (SimpleLogger) ============================== 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-585 ============================== Issue created ------------------------------ ILya Chilikin created this issue on 20/Mar/23 20:58 Summary: Broken link on website (SimpleLogger) Issue Type: Bug Affects Versions: 2.0.6 Assignee: SLF4J developers list Created: 20/Mar/23 20:58 Environment: Windows 10 Chrome 110 Labels: documentation Priority: Minor Reporter: ILya Chilikin Description: There is a broken link on web site https://www.slf4j.org/manual.html#swapping In text slf4j-simple-2.0.6.jar Binding/provider for Simple implementation ... "Simple" is a link leading to https://www.slf4j.org/apidocs/org/slf4j/impl/SimpleLogger.html which returns 404 Not Found error. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af) From slf4j-dev at qos.ch Mon Mar 20 22:49:00 2023 From: slf4j-dev at qos.ch (slf4j developers list) Date: Mon, 20 Mar 2023 22:49:00 +0100 (CET) Subject: [slf4j-dev] [JIRA] Updates for SLF4J-585: Broken link on website (SimpleLogger) In-Reply-To: References: Message-ID: SLF4J / SLF4J-585 [Resolved] Broken link on website (SimpleLogger) ============================== 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-585 ============================== 2 updates ------------------------------ Changes by Ceki Gülcü on 20/Mar/23 22:38 Resolution: Fixed Status: Resolved (was: In Progress) ============================== 1 comment ------------------------------ Ceki Gülcü on 20/Mar/23 22:38 [~Cyclone] Thank you for reporting this problem. The issue is now fixed. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af) From slf4j-dev at qos.ch Thu Mar 23 12:29:00 2023 From: slf4j-dev at qos.ch (slf4j developers list) Date: Thu, 23 Mar 2023 12:29:00 +0100 (CET) Subject: [slf4j-dev] [JIRA] Updates for SLF4J-488: Using slf4j-api-2.0.0-alpha1.jar not possible in OSGi In-Reply-To: References: Message-ID: SLF4J / SLF4J-488 [Open] Using slf4j-api-2.0.0-alpha1.jar not possible in OSGi ============================== 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-488 ============================== 1 comment ------------------------------ Hannes Wellmann on 23/Mar/23 12:18 Looks like a duplicate of SLF4J-457 that is fixed already. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af) From slf4j-dev at qos.ch Thu Mar 23 13:40:00 2023 From: slf4j-dev at qos.ch (slf4j developers list) Date: Thu, 23 Mar 2023 13:40:00 +0100 (CET) Subject: [slf4j-dev] [JIRA] Updates for SLF4J-557: MDCCloseable: not a great fit for a try-with-resources statement In-Reply-To: References: Message-ID: SLF4J / SLF4J-557 [In Progress] MDCCloseable: not a great fit for a try-with-resources statement ============================== 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-557 ============================== 1 comment ------------------------------ Alberto Scotto on 23/Mar/23 13:28 To make things more clear. Given the following test:   {code:java} @Test public void test() {   try (MDC.MDCCloseable ignored = MDC.putCloseable("k", "val")) {     log.info("BEGIN try");     throw new RuntimeException();   } catch (Exception e) {     log.error("FAILED try", e); // MDC will not be attached to this log at runtime!   } }{code}   Actual logs produced:   {noformat} 2023-03-23 13:21:37,535 INFO  MyTest k=val - BEGIN try 2023-03-23 13:21:37,537 ERROR MyTest k= - FAILED try {noformat} Expected: {noformat} 2023-03-23 13:21:37,535 INFO  MyTest k=val - BEGIN try 2023-03-23 13:21:37,537 ERROR MyTest k=val - FAILED try{noformat}   ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af) From slf4j-dev at qos.ch Thu Mar 23 18:23:00 2023 From: slf4j-dev at qos.ch (slf4j developers list) Date: Thu, 23 Mar 2023 18:23:00 +0100 (CET) Subject: [slf4j-dev] [JIRA] Updates for SLF4J-578: OSGi: jcl-over-slf4j does not export org.apache.commons.logging.impl In-Reply-To: References: Message-ID: SLF4J / SLF4J-578 [In Progress] OSGi: jcl-over-slf4j does not export org.apache.commons.logging.impl ============================== 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-578 ============================== 1 comment ------------------------------ Dr. Domagoj Ćosić on 23/Mar/23 18:12 I can confirm that it is fixed in 2.0.7 ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af) From slf4j-dev at qos.ch Fri Mar 24 16:56:00 2023 From: slf4j-dev at qos.ch (slf4j developers list) Date: Fri, 24 Mar 2023 16:56:00 +0100 (CET) Subject: [slf4j-dev] [JIRA] Updates for SLF4J-586: MANIFEST.MF exports a package with a former version number In-Reply-To: References: Message-ID: SLF4J / SLF4J-586 [Open] MANIFEST.MF exports a package with a former version number ============================== 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-586 ============================== Issue created ------------------------------ Frédéric Fays created this issue on 24/Mar/23 16:45 Summary: MANIFEST.MF exports a package with a former version number Issue Type: Bug Affects Versions: 2.0.7 Assignee: SLF4J developers list Components: Unspecified Created: 24/Mar/23 16:45 Environment: The MANIFEST.MF of slf4j.api, version *2.0.7* exports a package as version *1.7.36* Cf. MANIFEST.MF, line 12 Export-Package: org.slf4j;uses:="org.slf4j.event,org.slf4j.helpers,org.slf4j.spi";version="1.7.36" Please fix the version number to its effective version number, i.e. 2.0.7 (or whatsoever the current new version you are working on) Priority: Minor Reporter: Frédéric Fays ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af) From slf4j-dev at qos.ch Fri Mar 24 18:23:00 2023 From: slf4j-dev at qos.ch (slf4j developers list) Date: Fri, 24 Mar 2023 18:23:00 +0100 (CET) Subject: [slf4j-dev] [JIRA] Updates for SLF4J-586: MANIFEST.MF exports a package with a former version number In-Reply-To: References: Message-ID: SLF4J / SLF4J-586 [Open] MANIFEST.MF exports a package with a former version number ============================== 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-586 ============================== 1 comment ------------------------------ Ceki Gülcü on 24/Mar/23 18:12 [~frederic.fays] Thank you for this report. Is the change causing you trouble? The older version to "exports" directive was added on purpose and is not a mistake. Please see [PR 331|https://github.com/qos-ch/slf4j/pull/331] contributed by [~HannesWell]. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af) From slf4j-dev at qos.ch Fri Mar 24 19:04:00 2023 From: slf4j-dev at qos.ch (slf4j developers list) Date: Fri, 24 Mar 2023 19:04:00 +0100 (CET) Subject: [slf4j-dev] [JIRA] Updates for SLF4J-586: MANIFEST.MF exports a package with a former version number In-Reply-To: References: Message-ID: SLF4J / SLF4J-586 [Open] MANIFEST.MF exports a package with a former version number ============================== 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-586 ============================== 1 comment ------------------------------ Hannes Wellmann on 24/Mar/23 18:53 Exactly, please see also SLFJ4-579 for more background. Summed up, the intention is to allow libraries programmed against the slf4j-1 client api, which only import the package org.sfl4j with a version ranges like (1.x,2), to work with the slf4j-api in version 2 in OSGi runtimes as well. Therefore the slf4j.api bundle exports the package org.slf4j in version {{2.0.x}} and {{{}1.7.36{}}}. This is valid because the API in the org.slf4j package has not been broken from sfl4j-1 to 2 and slf4j is a drop-in replacement for slf4j-1 from the client perspective. Furthermore this allows much faster adoption of slf4j-2 in the OSGi world. Otherwise it would only be possible to update to slf4j-2 after all bundles of an application have been prepared for slf4j-2, which could take some time and could become complicated if libraries decide to require slf4j-2. Due to the nature of slf4j you don't want to slf4j.api bundles in your application. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af) From slf4j-dev at qos.ch Mon Mar 27 11:24:00 2023 From: slf4j-dev at qos.ch (slf4j developers list) Date: Mon, 27 Mar 2023 11:24:00 +0200 (CEST) Subject: [slf4j-dev] [JIRA] Updates for SLF4J-586: MANIFEST.MF exports a package with a former version number In-Reply-To: References: Message-ID: SLF4J / SLF4J-586 [Open] MANIFEST.MF exports a package with a former version number ============================== 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-586 ============================== 1 comment ------------------------------ Frédéric Fays on 27/Mar/23 11:12 Geki Gülcü : I'm struggling to load pax-logging-logback 2.2.2 bundle that has a dependency to org.slf4j.api bundle into Apache Karaf 4.4.2, and I go deep in the rabbit hole to spot anything that can prevent to have it happening. Not sure this issue is the root issue yet. Hannes Wellmann: thank you for pointing me to the comment thread of SLFJ4-579. And I understand the good intention to allow to use the slf4j-api version 2 artifact as drop-in replacement for slf4j-api version 1 in OSGi environments. And I will explain why it will not work as you intend. Here is my code analysis: within an OSGi container, to have a containment per bundle, each bundle will be loaded in its own Classloader, this allow to have two different versions of a bundle with same ids and same package names to be loaded simultaneously in memory. Imagine that I've a bundle that requires version 1.7.36 that is installed first, and that will automatically download the version 1.7.36, then later I install another bundle that explicitly requires the version 2.0.7, what will happen!? Both version 1.7.36 and 2.0.7 will be loaded in memory, each contained in their own Classloader, both expose the package org.slf4j as version "1.7.36" but its more than likely that for dependency resolution the OSGi bundle container will pick the first being declared, as on face value, they are equivalent. However this is untrue, because as example, the library 2.0.7 exposes new methods "org.slf4j.MDC.pushByKey", "org.slf4j.MDC.pushByKey" and "org.slf4j.MDC.getCopyOfDequeByKey", so if my second plugin that relies on version 2.0.7 needs to use any of these methods, it will end in a "NoSuchMethodError" error. In the opposite situation, if by any chance it is the version 2.0.7 that is taken into account along with package "org.slf4j.spi" of the version 1.7.36 then you will encounter a "NoSuchClassError" as the "org.slf4j.spi.SLF4JServiceProvider" class used by "org.slf4j.MDC" class does not exist in version 1.7.36 (I think this is less likely as I believe the OSGI container will try to resolve with the package dependency with the first bundle that matches the requirement) Long story short, please do make the life harder to the applications packagers... ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af) From slf4j-dev at qos.ch Mon Mar 27 20:03:00 2023 From: slf4j-dev at qos.ch (slf4j developers list) Date: Mon, 27 Mar 2023 20:03:00 +0200 (CEST) Subject: [slf4j-dev] [JIRA] Updates for SLF4J-586: MANIFEST.MF exports a package with a former version number In-Reply-To: References: Message-ID: SLF4J / SLF4J-586 [Open] MANIFEST.MF exports a package with a former version number ============================== 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-586 ============================== 1 comment ------------------------------ Ceki Gülcü on 27/Mar/23 19:51 [~frederic.fays] Am I wrong to assume that you have encountered {{NoSuchMethodError}} for {{org.slf4j.MDC.pushByKey}} or similar *in practice*? ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af) From slf4j-dev at qos.ch Mon Mar 27 21:54:00 2023 From: slf4j-dev at qos.ch (slf4j developers list) Date: Mon, 27 Mar 2023 21:54:00 +0200 (CEST) Subject: [slf4j-dev] [JIRA] Updates for SLF4J-586: MANIFEST.MF exports a package with a former version number In-Reply-To: References: Message-ID: SLF4J / SLF4J-586 [Open] MANIFEST.MF exports a package with a former version number ============================== 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-586 ============================== 1 comment ------------------------------ Hannes Wellmann on 27/Mar/23 21:42 Thank you for your elaboration and I want to say in advance that the intention and purpose of that change was to make the live of application packagers (and everybody else) easier. While you are absolutely right that one can load multiple bundles with the same Bundle-SymbolicName and same exported packages in different versions, I'm convinced that in case of SLF4J you should really only have one version of the slf4j.api bundle install in your OSGi runtime. Because slf4j.api 1 and 2 use different mechanism to wire the slf4j.api with a binding/provider you also need two bindings/providers, one for each version, that both have to be configured properly etc. and with other corner cases one probably gets a hard time setting up the loggers reliably. Although I have to admit that I have not yet tried it, but setting up one version of slf4j in OSGi can be difficult enough. And that is also what SLFJ4-579 should help with, because it allows you to only install one version of the slf4j.api bundle (i.e. version >=2.0.7) in your runtime and serve with it both kind of bundles, those that import the package org.slf4j with a 1.x and those that import a 2.x version range. You then only have to make sure that libraries that import the package {{{}org.slf4j.event{}}}, {{org.slf4j.helpers}} or {{org.slf4j.spi}} are compatible with slf4j-2. They either they have a version dedicated for slf4j-2 (and requires slf4j-2) or if they are compatible with both, they can just widen the version ranges for the imports of those packages to something like {{{}[1.7,3){}}}. See for example https://github.com/apache/mina-sshd/pull/336.   > Both version 1.7.36 and 2.0.7 will be loaded in memory, each contained in their own Classloader, both expose the package org.slf4j as version "1.7.36" but its more than likely that for dependency resolution the OSGi bundle container will pick the first being declared, as on face value, they are equivalent. The former statement is correct, for the latter statement it depends how 'greedy' the resolver of your OSGi runtime is in your case, but in general a OSGi resolver usually (AFAIK, but I'm not sure how much this is mandated) tries to minimise the number of wires and resolved/wired bundles. > However this is untrue, because as example, the library 2.0.7 exposes new methods "org.slf4j.MDC.pushByKey", "org.slf4j.MDC.pushByKey" and "org.slf4j.MDC.getCopyOfDequeByKey", so if my second plugin that relies on version 2.0.7 needs to use any of these methods, it will end in a "NoSuchMethodError" error. In that case your second Plugin/Bundle must import the package {{org.slf4j}} with a version range that has a lower bound of 2.0.7, then the {{NoSuchMethodError}} cannot happen because the second Plugin will always be wired to slf4j.api version 2.0.7 or above. If you have not specified such version range I can only encourage you to do so, to guard yourself from such errors.   > In the opposite situation, if by any chance it is the version 2.0.7 that is taken into account along with package "org.slf4j.spi" of the version 1.7.36 then you will encounter a "NoSuchClassError" as the "org.slf4j.spi.SLF4JServiceProvider" class used by "org.slf4j.MDC" class does not exist in version 1.7.36 (I think this is less likely as I believe the OSGI container will try to resolve with the package dependency with the first bundle that matches the requirement) If a Plugin/Bundle imports the packages {{org.slf4j}} and {{org.slf4j.spi}} both with a version range like [1.7,2) then the described case should also not be possible, because when exported packages use the {{{}uses{}}}-directive the OSGi container ensures classspace consistency and will not wire the slf4j.api-2 bundle to that Plugin in any case. I have written 'should' because the slf4j.api bundle in version 1 does not have those {{uses}} directives for its exported packages, only slf4j.api since version 2.0.6 has them. If slf4j.api version 1.7.x would have them too, the situation you have described would be definitely impossible. Nevertheless I believe that even at the moment it is unlikely because the OSGi resolver will probably minimize the number of wire providers for one bundle and will likely wire the Plugin you have described to slf4.api-1. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af) From slf4j-dev at qos.ch Wed Mar 29 15:26:00 2023 From: slf4j-dev at qos.ch (slf4j developers list) Date: Wed, 29 Mar 2023 15:26:00 +0200 (CEST) Subject: [slf4j-dev] [JIRA] Updates for SLF4J-586: MANIFEST.MF exports a package with a former version number In-Reply-To: References: Message-ID: SLF4J / SLF4J-586 [Open] MANIFEST.MF exports a package with a former version number ============================== 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-586 ============================== 1 comment ------------------------------ Frédéric Fays on 29/Mar/23 15:14 A big thank you for your feedback! [~HannesWell] >... it depends how 'greedy' the resolver of your OSGi runtime To my knowledge, there are only two OSGi runtimes implementation: Apache Felix and Eclipse Equinox, so it should be tested in both environments. [~ceki] >I wrong to assume that you have encountered NoSuchMethodError for org.slf4j.MDC.pushByKey or similar in practice? In practice - no However as explained below I'm struggling to load {{org.ops4j.pax.logging.pax-logging-logback}} bundle version 2.2.2 that has a dependency to {{org.slf4j.api}} bundle into Apache Karaf 4.4.2 configured to use Equinox as OSGi System Bundle. Currently I encounter a {{java.lang.ClassNotFoundException: org.slf4j.spi.LoggingEventAware}} cannot be found by {{org.ops4j.pax.logging.pax-logging-logback_2.2.2}} After analysis I discovered that the class {{org.slf4j.spi.LoggingEventAware}} exist starting version from version 2 of {{org.slf4j.api}} bundle, so not in version 1 of {{org.slf4j.api}}. After a long discussion with the pax-logging team (cf. [Manifest of pax-logging-logback has an {{Import-Package}} directive for {{org.slf4j}} version 1.7 instead of 2 #518|https://github.com/ops4j/org.ops4j.pax.logging/issues/518]), I discovered that root issue is that the bundle {{org.ops4j.pax.logging.pax-logging-api}} is bundling "foreign" packages (i.e. classes and packages that does not belong the pax-logging project). So to start with, I made the *wrong* assumption that a given bundle is only exporting packages matching its given version number. But digging into this rabbit hole, I have discovered this untrue, because... 1. The bad: {{slf4j.api}} bundle version 2.0.7 is exporting a package that is not matching its version. 2. The worse: {{org.ops4j.pax.logging.pax-logging-api}} is exporting packages that are not even part of its project! So in Karaf what do I see? {code:sh} karaf at root()> package:exports -p 'org.slf4j' {code} ||Package Name || Version || ID || Bundle Name|| |... | ... | .. | ...| |org.slf4j | 1.7.36 | 6 | org.ops4j.pax.logging.pax-logging-api| |org.slf4j | 1.7.36 | 58 | slf4j.api| {code:sh} karaf at root()> bundle:list -t 0 -n -s 0 6 58 {code} ||ID || State || Lvl || Version || Name || Symbolic name|| | 6 | Active | 8 | 2.1.3 | OPS4J Pax Logging - API | org.ops4j.pax.logging.pax-logging-api| |58 | Active | 80 | 2.0.7 | slf4j-api | slf4j.api| A none of these package exports are from the "legit" {{slf4j.api}} version 1.7.36 bundle! That has made to me a troubleshooting nightmare! So in both case, it starts from good intentions. I.e. 1. In the first case it does not requires to the packager to have to deploy the other bundles dependencies to org.ops4j.pax.logging.pax-logging-api 2. In the second case the intent is so offer the "nice to have" "early adoption" workaround for the bundles that are still wired to version 1. I believe such decisions might leads to maintenance dilemmas: I.e. Let's imagine there is new Common Vulnerabilities and Exposures published for org.slf4j version 1.7.36 and being fixed in version 1.7.37 ... what the maintainer should do? 1. Assume it does not impact org.slf4j version 2.0.7? 2. Remove version 2.0.7 (as we do not know the impact) and deploy version 1.7.37? 3. Option 3? The bottom line is that I maintain my issue statement, that the bundle {{slf4j.api}} should exports a package with a former version number. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af) From slf4j-dev at qos.ch Wed Mar 29 20:27:00 2023 From: slf4j-dev at qos.ch (slf4j developers list) Date: Wed, 29 Mar 2023 20:27:00 +0200 (CEST) Subject: [slf4j-dev] [JIRA] Updates for SLF4J-586: MANIFEST.MF exports a package with a former version number In-Reply-To: References: Message-ID: SLF4J / SLF4J-586 [Open] MANIFEST.MF exports a package with a former version number ============================== 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-586 ============================== 1 comment ------------------------------ Hannes Wellmann on 29/Mar/23 20:15 TL;DR: It looks like org.ops4j.pax.logging.pax-logging-api is to blame for the problems you encountered because they have incorrect OSGi metadata. > >... it depends how 'greedy' the resolver of your OSGi runtime > To my knowledge, there are only two OSGi runtimes implementation: Apache Felix and Eclipse Equinox, so it should be tested in both environments. According to Wikipedia there are more, but the ones you mentioned are probably the most relevant ones (AFAIK). Nevertheless even in Equinox we use the Felix Resolver: https://github.com/eclipse-equinox/equinox/tree/master/bundles/org.eclipse.osgi/felix/src/org/apache/felix/resolver Thank you @frederic.fays for the details. In order to verify that from slf4j side everything works as expected I created a little Eclipse application (using the Equinox OSGi framework) which, besides the basics for the Eclipse Platform and lockback 1.2 and 1.3 bindings/providers, has mainly two Bundles A and B with the following MANIFEST.MF files: {code:java} Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-SymbolicName: bundle.a Bundle-Version: 1.0.0.qualifier Import-Package: org.slf4j;version="[1.7.0,2.0.0)"{code}   {code:java} Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-SymbolicName: bundle.b Bundle-Version: 1.0.0.qualifier Import-Package:  org.slf4j;version="[1.7.0,2.0.0)",  org.slf4j.spi;version="[1.7.0,2.0.0)" {code}   Within the launched application I used the Felix GoGo Shell to analyse the resulting wiring within the Framework:   {code:java} g! p org.slf4j osgi.wiring.package; bundle-symbolic-name="slf4j.api"; bundle-version:Version="2.0.7"; version:Version="1.7.36"; osgi.wiring.package="org.slf4j"; uses:="org.slf4j.event,org.slf4j.helpers,org.slf4j.spi"   bundle.a_1.0.0.qualifier [4] imports osgi.wiring.package; bundle-symbolic-name="slf4j.api"; bundle-version:Version="1.7.36"; version:Version="1.7.36"; osgi.wiring.package="org.slf4j"   bundle.b_1.0.0.qualifier [5] imports   ch.qos.logback.classic_1.2.12 [7] imports osgi.wiring.package; bundle-symbolic-name="slf4j.api"; bundle-version:Version="2.0.7"; version:Version="2.0.7"; osgi.wiring.package="org.slf4j"; uses:="org.slf4j.event,org.slf4j.helpers,org.slf4j.spi"   ch.qos.logback.classic_1.3.6 [6] imports   org.apache.httpcomponents.client5.httpclient5_5.1.3.v20221013-1742 [45] imports   org.eclipse.jetty.util_10.0.13 [206] imports   ... {code}   This shows that Bundle A, which only imports the package {{org.slf4j}} below 2, is wired to the {{org.slf4j}} package from bundle {{slf4j.api}} version 2, while Bundle B, which imports {{org.slf4j}} and {{org.slf4j.spi}} below version 2, is wired to the {{org.slf4j}} package from the {{slf4j.api}} bundle in version 1.7. So in this case, when only the official {{slf4j.api}} bundle is used, everything works fine as expected and intended. Good for me, but the question remains why it does not work for you and after looking into the Manifest.MF in the jar of pax-logging-api:2.2.2 I noticed the following Export-Package entry: {code:java} Export-Package:  org.slf4j;version="2.0.6";provider=paxlogging;uses:="org.slf4j.event,org.slf4j.helpers,org.slf4j.spi",  org.slf4j;version="1.7.36";provider=paxlogging,  org.slf4j;version="1.6.6";provider=paxlogging,  org.slf4j;version="1.5.11";provider=paxlogging,  org.slf4j;version="1.4.3";provider=paxlogging,  org.slf4j.event;version="1.7.36";provider=paxlogging,  org.slf4j.event;version="2.0.6";provider=paxlogging;uses:="org.slf4j,org.slf4j.helpers",  org.slf4j.helpers;version="1.7.36";provider=paxlogging,  org.slf4j.helpers;version="1.6.6";provider=paxlogging,  org.slf4j.helpers;version="1.5.11";provider=paxlogging,  org.slf4j.helpers;version="1.4.3";provider=paxlogging,  org.slf4j.helpers;version="2.0.6";provider=paxlogging;uses:="org.slf4j,org.slf4j.event,org.slf4j.spi",  org.slf4j.spi;version="1.7.36";provider=paxlogging,  org.slf4j.spi;version="1.6.6";provider=paxlogging,  org.slf4j.spi;version="1.5.11";provider=paxlogging,  org.slf4j.spi;version="1.4.3";provider=paxlogging, org.slf4j.spi;version="2.0.6";provider=paxlogging;uses:="org.slf4j,org.slf4j.event,org.slf4j.helpers", ...{code}   It looks like pax-logging-api is doing something similar like slf4j-api, but the metadata are incorrect respectively insufficient. First of all as we have discussed in SLF4J-579 only the package org.slf4j is backwards compatible. So given that the embedded class files are shaded/copied from slf4j.api 2.0.6, exporting org.slf4j.event/helpers/event in any version below 2 is wrong, since some classes/methods are binary incompatible. This is the reason, why the slf4j.api bundles does not export them and I think that is the root of the problem here. In general it is not a problem in OSGi to re-bundle packages from other Bundles/Plugins as long as all packages are versioned correctly (following SemVer rules) have uses-constriaints and consumers only use Import-Package and not Require-Bundle. Then the actual bundle is just an exchangeable hull (which is even one design-goal of the Import/Export-Package mechanism if not OSGi). To quote a stackoverflow answer ([https://stackoverflow.com/a/7476016):|https://stackoverflow.com/a/7476016)] {code:java} An OSGi application will not throw ClassNotFoundExceptions and NoClassDefFoundErrors if your manifest is correct. That is, you need to tell OSGi which packages your bundle uses; if you don't do this correctly or honestly, then OSGi cannot help you. In other words: GIGO (Garbage In, Garbage Out).{code} And in my opinion at least the metadata of pax-logging-api are wrong. However after skimming over your linked issue, [https://github.com/ops4j/org.ops4j.pax.logging/issues/518] respectively [https://github.com/ops4j/org.ops4j.pax.logging/issues/519] it looks like the pax-logging devs are aware of what they are doing and they are doing it on purpose and since I believe they are reasonable people they probably do it for a reason. I'm not familiar with the exact Karaf/Pax/Container environment and did read the discussion in detail and therefore cannot assess their decision. But my naive first attempt would be, instead of shading/repacking the api classes from all supported facades into a own bundle, use the original (multiple) api bundles and provide a custom logging implementation/binding/provider that is wired to all the facades and does the redirection magic to whatever target or other logging-backend is intended. Basically just like all the other logging-backends and bridges work. But probably the pax-logging devs have considered that as well and had a reason to not do that. So to solve your issue I suggest you do what was suggested in [https://github.com/ops4j/org.ops4j.pax.logging/issues/518#issuecomment-1488132088] and simply not include the slf4j.api in your application. As far as I understand it, in your scenario it is not wanted any way and the pax-logging-api is intended as replacement for the slf4j.api bundle. Nevertheless I'm still not sure if that would change something for you, because with the latest pax-logging-api:2.2.2 you have a bundle that exports the {{org.slf4j}} package in multiple versions above and below two too and even the other {{org.slf4j.X}} packages in multiple versions. So even without slf4j.api, you would be in a similar scenario. Sorry, that is probably frustrating for you. Can you try the pax-logging 2.2.2 api and logback with slf4j.api 2.0.5? Version 2.0.5 export the package org.slf4j package only in version 2.0.x. If you have a Felix GoGo shell in your app, it would probably also be interesting to see the OSGi wires of the org.slf4j package. You can use the command I used above ({{{}g! p org.slf4j{}}}). Maybe the karaf runtime has something similar built in. But again, I'm convinced that the slf4j.api metadata are correct and work as intended as shown above and that you face the problems because of the specialities of pax-logging. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af) From slf4j-dev at qos.ch Fri Mar 31 18:48:00 2023 From: slf4j-dev at qos.ch (slf4j developers list) Date: Fri, 31 Mar 2023 18:48:00 +0200 (CEST) Subject: [slf4j-dev] [JIRA] Updates for SLF4J-586: MANIFEST.MF exports a package with a former version number In-Reply-To: References: Message-ID: SLF4J / SLF4J-586 [Open] MANIFEST.MF exports a package with a former version number ============================== 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-586 ============================== 1 comment ------------------------------ Frédéric Fays on 31/Mar/23 18:36 [~HannesWell] Thank you for your detailed analysis In fact I'm glad there has been a good fruitfull discussion on both projects. I.e. I remembered that not all is black and white, and I don't want to play the blame game, just attempting to add my inputs to the reflection. My mistake came from my assumption that an OSGi bundle can only provide packages from its own project. Since, I've learned that is it acceptable to re-bundle packages from other projects for convenience. So in issue [https://github.com/ops4j/org.ops4j.pax.logging/issues/519] discussion, the team explain why decision to packages from all facades of other logging API has been made. I still believe such choice makes the troubleshooting harder; On the other hand there is nothing in the OSGi specification ruling against it, so they made an acceptable pragmatic choice. In issue [https://github.com/ops4j/org.ops4j.pax.logging/issues/518] they emphasize there is the "provider=paxlogging" parameter in the Export-Package directive to enforce the OSGi system bundle to wire the package with pax-logging-api bundle. And for this issue, it is a project team choice as well. For which I still believe such choice makes the troubleshooting harder... I.e. If SLF4J users wants to adopt the version 2, they have to go for it and update their MANIFESTS (this is my opinion). Still if you think providing a backward compatibly for early adoption of SLF4j library is a good trade-off, it is your choice! And nothing in the OSGi specification ruling against it. So if your decision to {{Export-Package: org.slf4j;version="1.7.36"}} is final then please close this ticket. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)