[slf4j-dev] [JIRA] Updates for SLF4J-586: MANIFEST.MF exports a package with a former version number

[slf4j developers list]

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)