March 2023 - slf4j-dev - mailman3.qos.ch

[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

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

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

1 0

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

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

1 0

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

24 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. 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)

1 0

[JIRA] Updates for SLF4J-578: OSGi: jcl-over-slf4j does not export org.apache.commons.logging.impl
by slf4j developers list 23 Mar '23

23 Mar '23

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)

1 0