Help switching to SLF4J 2.0.9

[PatrickTasse]

In 2023-12 our project is switching our SLF4J dependencies,
from: org.slf4j.api/org.slf4j.binding.simple 1.7.30 from 2023-06 Orbit repo
to: slf4j.api/slf4j.simple 2.0.9 from 2023-12 Orbit aggregation repo

After the switch, the slf4j.simple binding no longer seems to be found by the LoggerFactory.

SLF4J: No SLF4J providers were found.
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See https://www.slf4j.org/codes.html#noProviders for further details.

Debugging, it seems that the logger factory is trying to find the bindings with ServiceLoader.load(SLF4JServiceProvider.class, classLoaderOfLoggerFactory), where the class loader is an EquinoxClassLoader[slf4j.api].

This should find SimpleServiceProvider from slf4j.simple bundle, but it does not. With test code I can also see that the slf4j.api Equinox class loader is not able to find the SimpleServiceProvider class.

What I noticed is that, in SLF4J 1.7.30, the org.slf4j.binding.simple is actually a fragment plugin with org.slf4j.api as the fragment-host. But in SLF4J 2.0.9, slf4j.simple is no longer a fragment of slf4j.api. This might explain why its class loader can no longer find the service from another plugin?

It so happens that in our project we have a fragment plugin of org.slf4j.api whose only purpose is to provide the simplelogger.properties resource, as this file must also be found by the org.slf4j.api class loader at initialization. So I tried adding the slf4j.simple as a dependency of our fragment plugin. This makes it now possible for the slf4j.api class loader to load the SimpleServiceProvider class in my test code. But the LoggerFactory still isn't able to find it using the ServiceLoader. Maybe ServiceLoader doesn't work with plugin fragments?

Does anyone have any idea how this is supposed to work? I don't know what I'm doing wrong. But then again, I know nothing, Jon Snow.

I read this: https://www.slf4j.org/faq.html#changesInVersion200, it just says both plugins must be in the classpath. I do see them in the Classpath of my test plugin (through Plug-In Dependencies), but slf4j.simple is presumably not in the classpath of the default slf4j.api plugin? And there are no Java Build Path properties for fragment plugins.

Thanks for any help,
Patrick

[merks]

@HannesWell

It would be great if you could share your insights and wisdom here!

I've already mentioned that product configuration is involved:

The EPP products have the above configuration as well as the Platform SDK...

@PatrickTasse

I assume you are trying to get this working when installed in an EPP product. If that's not the case, please clarify the context.

[PatrickTasse]

No, we don't enable that logging in our product. We only include the slf4j.binding for unit tests during the build through the pom.xml. Or by selecting the binding plugin in Run/Debug configuration of JUnit Plug-in Test in Eclipse development environment. We're doing this to see the SLF4J logging that is output by SWTBot widgets.

[HannesWell]

I can only confirm what has been said for products.

If you only want to enable logging in tests, the Auto-Start/Start-level configuration can be done in the Tycho-surefire Plugin configuration:
https://tycho.eclipseprojects.io/doc/latest/tycho-surefire-plugin/test-mojo.html#bundleStartLevel

[jonahgraham]

@merks's provides the specific example of what needs to change, the N&N entry that covers this is: https://eclipse.dev/eclipse/news/4.28/platform.php#slf4j.api-version-2

You can see what EPP changed to take advantage of this: eclipse-packaging/packages#43 (contains start level changes) + eclipse-packaging/packages#47 (add slf4j.simple to the product in case it isn't already there)

[PatrickTasse]

Thank you all for your help. It works!

For the Jenkins build, I configured the bundleStartLevel with autoStart set to true for org.apache.aries.spifly.dynamic.bundle and slf4j.simple in the pom.xml for our SWTBot unit test profile.

For local testing, we have to manually set the Auto-Start to "true" for these two plug-ins in the JUnit Plug-in Test Run/Debug
Configuration in Eclipse.

It's a hassle for our developers though, they can't use the default "All workspace and enabled target plug-ins", and they'll have to change this for every test configuration. I wonder if there is a way to set this automatically in the test plug-in project?

Another issue I had to fix... Because slf4j.simple is no longer a fragment of slf4j.api but is a real plug-in, it is its own class loader that attempts to load simplelogger.properties. As a consequence, our own fragment plug-in must change its fragment-host to be slf4j.simple instead of slf4j.api, otherwise slf4j.simple does not find our properties file and we get the wrong logging level.