Use Slf4J with OSGi (possibly without SPI)

[MSchmidke]

Hi all,

I'm dealing with a RCP/OSGi/Equinox application and currently trying to update to SLF4J2.x.

One big drawback I can see is the move to forcedly use SPI to discover the proper logging adapter. In a normal Java environment this might be very elegant, but with OSGi it introduces such a huge pile of dependencies (at least Apache SpiFly, which in turn comes with a lot of other dependencies), and all of this just to discover that I'm using Log4J.

Is there any way to get around the SPI way and to directly configure the adapter?

(Admittedly, this might require a different build with different dependencies, since the dependencies are what makes my problem, not the missing configuration option)

Any help is appreciated!

Marcus.

[ceki]

@MSchmidke As of slf4j version 2.0.9, org.slf4j.LoggerFactory allows loading an SLF4JServiceProvider class explicitly specified with the slf4j.provider system property. You can thus circumvent the nominal search via the java.util.ServiceLoader mechanism.

The only restriction is that the specified loader must be loadable by the class loader that loader that loaded org.slf4j.LoggerFactory.

[MSchmidke]

As you are writing this, I remember I also tried this way. Unfortunately this didn't work because Slf4J tries to load this class via its own classloader, which is not possible in OSGi. Either I need a possibility to set it the programmatic way, or I have to repackage Slf4j with modified MANIFEST (registering a Buddy-Policy, for example).

(Unfortunately, I got interrupted and forgot to send this reply. In the meantime there arrived a new response from ppkarwasz ... ;-) )

[ppkarwasz]

@ceki,

Setting slf4j.provider in an OSGi environment without a Service Loader Mediator will not work, since the classloader of slf4j-api does not see the classes of the SLF4J implementation.

@MSchmidke,

If you are looking to deploy SLF4J in an OSGi environment without SLM, consider using the PAX Logging bundles. The pax-logging-api contains SLF4J, Log4j API, Commons Logging and several other logging APIs. It uses primitive OSGi methods to bind with a pax-logging-* implementation (Log4j 2 Core or Logback).

Remark: since ServiceLoader is the only lookup service that reliably works in both an OSGi and JPMS environment and given the ubiquity of SLF4J, Log4j 3 Core also abandoned its custom OSGi code and requires SLM in an OSGi environment.

[MSchmidke]

PAX sounds interesting, thank you for your suggestion!

Perhaps it won't work out of the box because we were so glad having managed to have all third parties in one Logfile (with the old Slf4j1 setup), no matter if they themselves are using SLF4J, Log4J or Java logging, but it could be a good starting point.

[ppkarwasz]

All logging APIs in pax-logging-api are hardcoded to use the same logging backend.

[Holzmacher]

I found a workaround to use slf4j without Service Loader Mediator:
https://stackoverflow.com/questions/78783619/logback-logger-1-5-0-with-eclipse-4-31-no-slf4j-providers-were-found