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@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@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)