slf4j missing uses constraints

[jonahgraham]

The SLF4J is missing uses constraints. This leads to runtime errors like this (I added line breaks for readability) if there are multiple versions of slf4j installed.

loader constraint violation: 
  when resolving method 'org.slf4j.ILoggerFactory org.slf4j.impl.StaticLoggerBinder.getLoggerFactory()' 
  the class loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @3a07fd19 of the current class, 
    org/slf4j/LoggerFactory, and 
  the class loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @773560cf for the method's defining class, 
    org/slf4j/impl/StaticLoggerBinder, 
  have different Class objects for the type org/slf4j/ILoggerFactory used in the signature
  (org.slf4j.LoggerFactory is in unnamed module of loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @3a07fd19,
       parent loader 'platform'; 
   org.slf4j.impl.StaticLoggerBinder is in unnamed module of loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @773560cf, 
       parent loader 'platform')

[jonahgraham]

A workaround is to make sure that only a single version of SLF4J is installed.

[HannesWell]

A workaround is to make sure that only a single version of SLF4J is installed.

That should be the goal also to ensure the logging works correctly.
But having technical support to enforce this would be still good.

On the other hand that would make it impossible to use two libraries where one requires strictly slf4j<2 (because it has not yet updated its import-package ranges) and the other requires slf4j>=2. The logging will then likely be flaky, but if one does not care about that, it is not possible anymore.

[akurtakov]

Is there anything to do on releng side here or it can be closed?

[jonahgraham]

Is there anything to do on releng side

I think so, the slf4j that platform now pulls in has no uses clauses (unlike the slf4j that orbit repackages). This leads to wiring errors.

I understand the move away from orbit, but if the upstream package is missing uses clauses and we encourage consumers of slf4j to use import package, then we should ensure that uses clauses exist.

[akurtakov]

I hope that someone will open issue against slf4j requesting uses clauses to be added.

[jonahgraham]

https://jira.qos.ch/browse/SLF4J-574

[HannesWell]

Thank you Jonah for string qos-ch/slf4j#324.
Just adding it to have a cross-reference.

[akurtakov]

New slf4j version with Jonah's change has been released qos-ch/slf4j@v_2.0.5...v_2.0.6 . Please provide the needed updates so we can finish this one.

[jonahgraham]

@HannesWell can you make this change in platform?

[ruspl-afed]

Does it mean that Platform is going to switch to SLF4J 2.x?

[HannesWell]

@HannesWell can you make this change in platform?

Yes, I do. But after looking in more detail in your change I noticed that it for example changed the BSN. At the moment slf4j has now a mixtured of generating the manifest and using static manifest files under version control. I have started to prepare a follow-up on your change and plan to complete it this evening, that completely migrates to generating the manifests, thus removing all static manifest files.

Does it mean that Platform is going to switch to SLF4J 2.x?

Yes, we do. See #588

But I'm considering (and bndtools/bnd#5477 (comment) strengthened this consideration) to ask SLF4J to export its packages in a 1.7.x version and 2 version, so that libaries that import slf4j below version 2 can just use slf4j-2 without changes.

[HannesWell]

@HannesWell can you make this change in platform?

Yes, I do. But after looking in more detail in your change I noticed that it for example changed the BSN. At the moment slf4j has now a mixtured of generating the manifest and using static manifest files under version control. I have started to prepare a follow-up on your change and plan to complete it this evening, that completely migrates to generating the manifests, thus removing all static manifest files.

Created qos-ch/slf4j#327.

[merks]

I noticed this resolution failure (in Tycho 4.0.0-SNAPSHOT) when trying to fully resolve the requirements of slf4j-api version 2.0.6

Missing requirement: org.slf4j.api 2.0.6 requires 'osgi.extender; (&(osgi.extender=osgi.serviceloader.processor)(version>=1.0.0)(!(version>=2.0.0)))' but it could not be found

What is supposed to satisfy that requirement?

[HannesWell]

The (reference) Implementation of the OSGi ServiceLoader Mediator specification I usually use is Apache Aries SPI-fly:

• https://aries.apache.org/documentation/modules/spi-fly.html

• https://mvnrepository.com/artifact/org.apache.aries.spifly/org.apache.aries.spifly.dynamic.bundle

That should provide that capabilty.

[merks]

Okay, that helps! With that included, it gets to this failure:

Missing requirement: org.slf4j.api 2.0.6 requires 'osgi.serviceloader; (osgi.serviceloader=org.slf4j.spi.SLF4JServiceProvider)' but it could not be found

[HannesWell]

Okay, that helps! With that included, it gets to this failure:

Missing requirement: org.slf4j.api 2.0.6 requires 'osgi.serviceloader; (osgi.serviceloader=org.slf4j.spi.SLF4JServiceProvider)' but it could not be found

Do you have a recent SLF4J-provider in the TP? In case of Eclipse-Platform we probably want to only reference to no-op provider and let actual application/product builds choose a suitable one for them:
https://mvnrepository.com/artifact/org.slf4j/slf4j-nop/2.0.6

[merks]

That fixes the problem! You're the best. 🚀

[akurtakov]

Should this one be closed now?

[HannesWell]

Should this one be closed now?

Unfortunately the metadata of the current slf4j-release are still different than before in same parts:

@HannesWell can you make this change in platform?

Yes, I do. But after looking in more detail in your change I noticed that it for example changed the BSN. At the moment slf4j has now a mixtured of generating the manifest and using static manifest files under version control. I have started to prepare a follow-up on your change and plan to complete it this evening, that completely migrates to generating the manifests, thus removing all static manifest files.

Therefore I'm not sure if we should use that version.
I created qos-ch/slf4j#327 to fix that but that change was considered to large. As requested I created a reduced follow-up qos-ch/slf4j#330, but that did not yet get any attention.
So if anyone of you can help to motivate the SLF4J-maintainer for the latter PR that would help.
Otherwise we have to go with the changed metadata.

[HannesWell]

The mentioned SLF4J PR is merged and released as slf4j-api 2.0.7.
Created #981 to update. With that the metadata should now be fine.