[prev in list] [next in list] [prev in thread] [next in thread] 

List:       slf4j-dev
Subject:    [slf4j-dev] [JIRA] Updates for SLF4J-579: Export slf4j packages in version 1 and 2 in OSGi-Manifests
From:       slf4j developers list via slf4j-dev <slf4j-dev () qos ! ch>
Date:       2023-04-27 9:41:00
Message-ID: mailman.1167.1682588460.23762.slf4j-dev () qos ! ch
[Download RAW message or body]

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)

_______________________________________________
slf4j-dev mailing list
slf4j-dev@qos.ch
https://mailman.qos.ch/cgi-bin/mailman/listinfo/slf4j-dev


[prev in list] [next in list] [prev in thread] [next in thread]