[slf4j-dev] [JIRA] Updates for SLF4J-579: Export slf4j packages in version 1 and 2 in OSGi-Manifests

[slf4j developers list]

SLF4J / SLF4J-579 [Resolved]
Export slf4j packages in version 1 and 2 in OSGi-Manifests

==============================

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-579

==============================
 1 comment
------------------------------

Grzegorz Grzybek on 27/Apr/23 11:30

Let me add some OSGi information here.

It is extremely important to never forget that from OSGi point of view, the version of the library (Maven version), which usually, by default, but not necessarily becomes a _bundle version_ is not very important in OSGi runtime.
What is important is the version of package(s) inside the jar/bundle. This is especially visible in libraries like [OSGi Core|https://repo1.maven.org/maven2/org/osgi/osgi.core/8.0.0/] - the bundle and library has version 8.0.0, but the packages inside have versions like:
* 1.5.3 ({{org.osgi.util.tracker}})
* 1.0.1 ({{org.osgi.resource.dto}})
* ...

Slf4j-api library, which is proper OSGi bundle can indeed export the same package with two versions. The benefit is that whether the developer uses slf4j-api 1.7.x or 2.0.x, it'll work at OSGi runtime whether slf4j-api 1.7.x or 2.0.x is installed as a bundle.

But let's leave the OSGi ideals behind. In practice, one can never forget about actual implementation which is used. The analogous promise that if you use pure JPA API only, your application will work smoothly without changes with Hibernate or Eclipse Link comes to mind...

One simply has to know the actual mechanism with which slf4j-api discovers/binds-to actual implementation. OSGi specification doesn't cover the situation, where the major (incompatible) version is bumped because internal mechanism has changed. And this is the case here. {{org.slf4j}} package is actually compatible - the interface of Logger didn't change. However the backend is discovered differently...

I'll add a comment about [Pax Logging|https://github.com/ops4j/org.ops4j.pax.logging] under SLF4J-586, but here I'll only mention that pax-logging-api bundle includes (and re-exports) {{org.slf4j}} package with multiple versions (1.4, 1.5, 1.6, 1.7 and 2.0) - but it also includes (re-exports) packages for several other _logging facades_:
* Log4j1 API
* Log4j2 API
* JBoss Logging API
* Avalon Logging API
* Knopflerfish Logging API
* Tomcat JULI API
* Apache Commons Logging API
* OSGi Logging Service API
* Pax Logging API (own API)

In ideal world, you'd _simply_ install API bundles for all of the above and use some other fancy OSGi mechanisms (like SPI-Fly to manipulate TCCL for ServiceLoader) to get them working as you like.

Pax Logging took pragmatic approach and:
* removes the need to install 9 bundles to get 9 logging facade APIs
* re-exports (by repackaging the classes from original libraries) the above API packages
* changes some of the classes from the above packages - for example {{org.apache.log4j.LogManager}} from Log4j1 (Reload4j) is taken and entire static block (where the discovery happens) is removed, because we know we have to delegate to OSGi machinery

This approach allows Pax Logging to provide fancy scenarios like allowing old libraries which use Log4j1 API directly to use Log4j1 API (this is tricky in Log4j1, because {{org.apache.log4j.Logger}} class is both API and implementation...), use log() methods and get logging handled by Log4j2.
It allso allows Log4j2 API log calls to be handled by Logback backend (if chosen by configurator of Apache Karaf, which uses Pax Logging).

Summarizing - there's completely nothing wrong with _canonical_ (non-repackaged) slf4j-api providing two versions of {{org.slf4j}} package. However if you choose to use this bundle, it's up to you to make it working with Logback (exporting {{org.slf4j.logback}} package to give you StaticLoggerBinder for SLF4J 1.7) - and up to you to resolve conflict if someone installs log4j-slf4j-impl in the same runtime.


==============================
 This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)