- slf4j-dev - mailman3.qos.ch

[JIRA] Updates for SLF4J-587: Website: Misleading reference to user manual
by slf4j developers list 02 May '23

02 May '23

SLF4J / SLF4J-587 [Resolved] Website: Misleading reference to user manual ============================== 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-587 ============================== 2 updates ------------------------------ Changes by Ceki Gülcü on 02/May/23 17:57 Resolution: Fixed Status: Resolved (was: Open) ============================== 1 comment ------------------------------ Ceki Gülcü on 02/May/23 17:58 [~Chealer] Thank you for your remarks. The changes were made according your suggestions. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] Updates for SLF4J-587: Website: Misleading reference to user manual
by slf4j developers list 02 May '23

02 May '23

SLF4J / SLF4J-587 [Open] Website: Misleading reference to user manual ============================== 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-587 ============================== Issue created ------------------------------ Philippe Cloutier created this issue on 02/May/23 17:40 Summary: Website: Misleading reference to user manual Issue Type: Bug Assignee: SLF4J developers list Created: 02/May/23 17:40 Priority: Trivial Reporter: Philippe Cloutier Severity: trivial Description: The second paragraph of [the homepage|https://www.slf4j.org/] reads: ??Before you start using SLF4J, we highly recommend that you read the two-page SLF4J user manual.?? The "two-page" qualifier convinced me to follow the recommendation and go to [the user manual|https://www.slf4j.org/manual.html] But halfway through reading it, I realized it was much longer than I had expected. In my browser, on a monitor much bigger than average with the viewport occupying 2560x1674 pixels, at default zoom, the user manual's content is more than 7-page-long. While there may exist a screen which fits that manual in less than 3 pages, I assume the addition of content like _Salient historical changes_ and - more importantly - the _Fluent Logging API_ section has made the paragraph outdated, to the point of being misleading at this point. The user manual remains definitely useful and suggesting it remains a good idea, but the paragraph should be improved. I suggest: # to drop the "two-page" qualifier or replace it with something vaguer like "concise" # to clarify what is meant by "Before you start using SLF4J". Perhaps replace with "Before you adopt SLF4J" # perhaps just "recommend" reading rather than "highly recommend" it ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] Updates for SLF4J-586: MANIFEST.MF exports a package with a former version number
by slf4j developers list 27 Apr '23

27 Apr '23

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 ------------------------------ Grzegorz Grzybek on 27/Apr/23 13:02 Joining late to the interesting discussion ;) I've [added a comment under SLF4J-579|https://jira.qos.ch/browse/SLF4J-579?focusedId=21699&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-21699], but let me elaborate a bit more here. [~frederic.fays], about the summary of this issue: "MANIFEST.MF exports a package with a former version number" You're not 100% right assuming that it's something wrong. osgi.core-8.0.0.jar exports several (~20?) packages with versions starting with {{1.0}} and it's not a problem. While OSGi has a notion of "bundle version", what is important for the resolver (and recommended usage of {{Import-Package}} instead of {{Require-Bundle}}) is the package version(s). {{org.slf4j}} package didn't change that much between version 1.7.x and 2.0.x, so from SemVer point of view, the major upgrade is not justified. In practice we (developers) are so much used to bundle/library versions ({{<version>}} in Maven POMs) that it's _natural_ for use to translate this to package versions. This is nightmare for Guava users in OSGi... >From OSGi point of view, SemVer has very important role and nothing in OSGi spec says that the bundle (library) version SHOULD (or even MAY) translate to package version. But the blame goes to bnd/maven-bundle-plugin which calculates package versions from Maven version (and generates {{[version, next-major)}}). [~HannesWell]: bq. Furthermore this allows much faster adoption of slf4j-2 in the OSGi world. I'll never stop thinking about configured (in terms of installed bundles) OSGi runtime as _application server_. And for JavaEE, by "faster adoption of Servlet API 6" you don't mean "faster adoption of https://repo1.maven.org/maven2/jakarta/servlet/jakarta.servlet-api/6.0.0/ja…", but "faster adoption of application servers implementing Servlet API 6". {{<provided>}} scope for Maven does exactly this - you should not treat {{<provided>}} deps as part of the deployment, but part of the contract (requirement) of your app. Same for slf4j-api JAR - if you create OSGi application, you don't assume you'll copy this JAR along with your application. You assume there'll be something provided at runtime. And that's how pax-logging-api satisfies the "provided" dependency to SLF4J API. [~frederic.fays]: bq. The worse: org.ops4j.pax.logging.pax-logging-api is exporting packages that are not even part of its project! As discussed under https://github.com/ops4j/org.ops4j.pax.logging/issues/519 and https://github.com/ops4j/org.ops4j.pax.logging/issues/518 you should stop worry and accept this ;) This practice is inherent for OSGi programming since it's dawn. If you look at https://github.com/apache/servicemix-bundles/ project, you'll find tons of bundles released to repackage other libraries under different groupId and artifactId to fix wrong or non-existing OSGi metadata. Don't make me ask you to look inside https://repo1.maven.org/maven2/net/sf/ehcache/ehcache/2.10.9.2/ehcache-2.10…. Really - nothing to see there ;) Don't look. {quote} And for this issue, it is a project team choice as well. For which I still believe such choice makes the troubleshooting harder... {quote} Yes. And no. If you have CVE in Tomcat library from {{CATALINA_HOME/lib}}, what do you do? Change your application? Change the library in Tomcat? Patch the Tomcat? Replace the Tomcat? It depends. At some point the size of your application server justifies replacement. At some point it's better to patch. Real life example (from my field). Red Hat Fuse is based on Apache Karaf, which uses Pax Logging API + Pax Logging Log4j2. Pax Logging API repackages log4j1 (now reload4j) and 8 other Logging API facades. During [Log4j2 apocalypse|https://www.lunasec.io/docs/blog/log4j-zero-day/] we had to "fix the problem". During few days starting from Dec 10th 2021, I've released about 20 different versions of pax-logging. I managed to do it alone. It was painful, it wasn't only a matter of deployment to Maven Central, we also had to prepare patches for Fuse/Karaf (using Fuse own patching mechanism). And what if the change was needed only in Log4j2? It wouldn't be much different... So troubleshooting, maintenance and sustaining of the software is a complex subject. Assuming that bundles should export only own packages and only with versions matching the version of entire lib is simply unrealistic, though very appealing. h4. Summarizing [~HannesWell] bq. 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. Just as you rarely assemble your own JavaEE application server using API jars from https://repo1.maven.org/maven2/jakarta/ and own scripts, it's not common you assemble your own OSGi server. Apache Karaf is one of the distros which does the plumbing for you and one of the built-in features is working logging subsystem. Pax Logging (just two bundles) gives you 9 Logging facades and Log4j2 (or Logback) backed configurable using OSGi Configuration Admin ({{org.ops4j.pax.logging}}) PID. Now imagine you do it the _canonical_, pure way. You'd need: * 9 API bundles (Log4j1 API, Log4j2 API, JBoss Logging API, Avalon Logging API, Knopflerfish Logging API, Tomcat JULI API, Apache Commons Logging API, OSGi Logging Service API, Pax Logging API (own API)). * the _magic_ mentioned by [~HannesWell] to ensure that each of the above will properly, without deadlocks and memory leaks, preserving OSGi ClassLoading and package constraints _bind_ to single (you don't want logging performed by Log4j2 AND Logback at the same time, don't you?) logging implementation. Do you know how to tell JBoss Logging to properly delegate to Log4j2 (JBoss Logging scans the CLASSPATH, without knowing it works in OSGi, were effectively you don't have CLASSPATH)? And do you know how to configure Logging levels in single configuration file, so Tomcat JULI API will obey the rules? When you solve these problems, you'll eventually get to a solution similar to Pax Logging... I'm only a Pax Logging janitor - the project was created by ninjas before me. But it taught me to look at the reality while knowing the ideals ;) ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] Updates for SLF4J-579: Export slf4j packages in version 1 and 2 in OSGi-Manifests
by slf4j developers list 27 Apr '23

27 Apr '23

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 ------------------------------ Grzegorz Grzybek on 27/Apr/23 11:30 Let me add some OSGi information here. It is extremely important to never forget that from OSGi point of view, the version of the library (Maven version), which usually, by default, but not necessarily becomes a _bundle version_ is not very important in OSGi runtime. What is important is the version of package(s) inside the jar/bundle. This is especially visible in libraries like [OSGi Core|https://repo1.maven.org/maven2/org/osgi/osgi.core/8.0.0/] - the bundle and library has version 8.0.0, but the packages inside have versions like: * 1.5.3 ({{org.osgi.util.tracker}}) * 1.0.1 ({{org.osgi.resource.dto}}) * ... Slf4j-api library, which is proper OSGi bundle can indeed export the same package with two versions. The benefit is that whether the developer uses slf4j-api 1.7.x or 2.0.x, it'll work at OSGi runtime whether slf4j-api 1.7.x or 2.0.x is installed as a bundle. But let's leave the OSGi ideals behind. In practice, one can never forget about actual implementation which is used. The analogous promise that if you use pure JPA API only, your application will work smoothly without changes with Hibernate or Eclipse Link comes to mind... One simply has to know the actual mechanism with which slf4j-api discovers/binds-to actual implementation. OSGi specification doesn't cover the situation, where the major (incompatible) version is bumped because internal mechanism has changed. And this is the case here. {{org.slf4j}} package is actually compatible - the interface of Logger didn't change. However the backend is discovered differently... I'll add a comment about [Pax Logging|https://github.com/ops4j/org.ops4j.pax.logging] under SLF4J-586, but here I'll only mention that pax-logging-api bundle includes (and re-exports) {{org.slf4j}} package with multiple versions (1.4, 1.5, 1.6, 1.7 and 2.0) - but it also includes (re-exports) packages for several other _logging facades_: * Log4j1 API * Log4j2 API * JBoss Logging API * Avalon Logging API * Knopflerfish Logging API * Tomcat JULI API * Apache Commons Logging API * OSGi Logging Service API * Pax Logging API (own API) In ideal world, you'd _simply_ install API bundles for all of the above and use some other fancy OSGi mechanisms (like SPI-Fly to manipulate TCCL for ServiceLoader) to get them working as you like. Pax Logging took pragmatic approach and: * removes the need to install 9 bundles to get 9 logging facade APIs * re-exports (by repackaging the classes from original libraries) the above API packages * changes some of the classes from the above packages - for example {{org.apache.log4j.LogManager}} from Log4j1 (Reload4j) is taken and entire static block (where the discovery happens) is removed, because we know we have to delegate to OSGi machinery This approach allows Pax Logging to provide fancy scenarios like allowing old libraries which use Log4j1 API directly to use Log4j1 API (this is tricky in Log4j1, because {{org.apache.log4j.Logger}} class is both API and implementation...), use log() methods and get logging handled by Log4j2. It allso allows Log4j2 API log calls to be handled by Logback backend (if chosen by configurator of Apache Karaf, which uses Pax Logging). Summarizing - there's completely nothing wrong with _canonical_ (non-repackaged) slf4j-api providing two versions of {{org.slf4j}} package. However if you choose to use this bundle, it's up to you to make it working with Logback (exporting {{org.slf4j.logback}} package to give you StaticLoggerBinder for SLF4J 1.7) - and up to you to resolve conflict if someone installs log4j-slf4j-impl in the same runtime. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] Updates for SLF4J-586: MANIFEST.MF exports a package with a former version number
by slf4j developers list 31 Mar '23

31 Mar '23

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)

1 0

[JIRA] Updates for SLF4J-586: MANIFEST.MF exports a package with a former version number
by slf4j developers list 29 Mar '23

29 Mar '23

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.… 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"<slf4j.api_2.0.7 [319]> 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"<slf4j.api_1.7.36 [320]> 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"<slf4j.api_2.0.7 [319]> 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-1488…] 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)

1 0

[JIRA] Updates for SLF4J-586: MANIFEST.MF exports a package with a former version number
by slf4j developers list 29 Mar '23

29 Mar '23

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)

1 0

[JIRA] Updates for SLF4J-586: MANIFEST.MF exports a package with a former version number
by slf4j developers list 27 Mar '23

27 Mar '23

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)

1 0

[JIRA] Updates for SLF4J-586: MANIFEST.MF exports a package with a former version number
by slf4j developers list 27 Mar '23

27 Mar '23

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)

1 0

[JIRA] Updates for SLF4J-586: MANIFEST.MF exports a package with a former version number
by slf4j developers list 27 Mar '23

27 Mar '23

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)

1 0