[slf4j-dev] OSGi support in slf4j

[Heiko Seeberger]

Thank you for reviewing!

If I understand correctly we should relax the versioning policy to
import ranges from x.y instead of x.y.z, right? IMHO that makes sense.
An it's easily done: Just a little switch in the config. Let me know
and I will change it.

Heiko

On Tuesday, November 2, 2010, Hugues Malphettes <hmalphettes at intalio.com> wrote:
> Hi Ceki,Thanks for reminding us to review the changes introduced by BND.
> On Mon, Nov 1, 2010 at 2:16 PM, Ceki Gülcü <ceki at qos.ch> wrote:
> Hello all,
>
> I pulled in changes made by Heiko http://github.com/ceki/slf4j/pull/2. Here is the version of the MANIFEST file from slf4j-api-1.6.1.jar.
>
> Manifest-Version: 1.0
> Archiver-Version: Plexus Archiver
> Created-By: Apache Maven
> Built-By: ceki
> Build-Jdk: 1.6.0_16
> Bundle-Description: The slf4j API
>
> Bundle-Version: 1.6.1
> Implementation-Version: 1.6.1
> Implementation-Title: slf4j-api
> Bundle-ManifestVersion: 2
> Bundle-SymbolicName: slf4j.api
> Bundle-Name: slf4j-api
> Bundle-Vendor: SLF4J.ORG
> Bundle-RequiredExecutionEnvironment: J2SE-1.3
> Export-Package: org.slf4j;version=1.6.1, org.slf4j.spi;version=1.6.1,
>  org.slf4j.helpers;version=1.6.1
> Import-Package: org.slf4j.impl;version=1.6.0
>
> Here is the version generated after Heiko's changes have been applied:
>
> Manifest-Version: 1.0
> Export-Package: org.slf4j.spi;uses:="org.slf4j";version="1.6.2.SNAPSHO
>  T",org.slf4j.helpers;uses:="org.slf4j.spi,org.slf4j";version="1.6.2.S
>  NAPSHOT",org.slf4j;uses:="org.slf4j.helpers,org.slf4j.spi";version="1
>  .6.2.SNAPSHOT"
> Ignore-Package: org.slf4j.impl
> Implementation-Title: slf4j-api
>
> Built-By: ceki
> Tool: Bnd-0.0.357
>
> Bundle-Name: SLF4J API Module
>
> Created-By: Apache Maven Bundle Plugin
>
> Bundle-RequiredExecutionEnvironment: J2SE-1.4
>
> Bundle-Vendor: QOS.ch
> Build-Jdk: 1.6.0_16
> Bundle-Version: 1.6.2.SNAPSHOT
>
> Bnd-LastModified: 1288644768461
> Bundle-ManifestVersion: 2
> Bundle-License: http://www.opensource.org/licenses/mit-license.php
> Bundle-Description: The slf4j API
> Bundle-DocURL: http://www.qos.ch
>
> Bundle-SymbolicName: org.slf4j.api
> Import-Package: org.slf4j;version="[1.6.2.SNAPSHOT,1.7)",org.slf4j.hel
>  pers;version="[1.6.2.SNAPSHOT,1.7)",org.slf4j.spi;version="[1.6.2.SNA
>  PSHOT,1.7)"
>
>
> Admittedly, I am a little lost. The previous MANIFEST file imported org.slf4j.impl, whereas the latest MANIFEST does not. Strangely enough, org.slf4j.impl is not mentioned at all.
> Heiko packages org.slf4j.impl as bundle fragments that are hosted by org.slf4j.api.
>
> In our situation, there must not be more than one provider of org.slf4j.impl: this means there must one and exactly one fragment that provides org.slf4j.impl.
>
> At runtime the fragment classes are part of the classloader of org.slf4j.api.This is why org.slf4j.api does not import org.slf4j.impl at all.
> The MANIFEST.MF of org.slf4j.api does look good.
>
> It contains a few of extra lines that are read by BND alone: Private-Package and Bnd-LastModified for example.
>
>
> The MANIFEST.MF of jcl.over.slf4j (aka jcl-over-slf4j) uses these statements: Export-Package: org.apache.commons.logging;version=1.1.1,  org.apache. commons.logging.impl;version=1.1.1
>
> Import-Package: org.slf4j;version=1.6.2.SNAPSHOT, org.slf4j.spi;versio n=1.6.2.SNAPSHOT
> It will work.The versioning constrain on the import-package is I think too much: strictly speaking, the produced fragment is going to work with version 1.6 of slf4j.
>
> I apologize for sounding picky and in the case where we always build and distribute together slf4j-api and jcl-over-slf4j it probably does not matter much.If we were to adopt BND to generate the MANIFESTs of logback let's make sure that we generate version=1.6 only so that we don't suddenly force everyone to upgrade both slf4j and logback at once for no actual reason.
>
>
> Best regards,Hugues
>
>
>
>
> In earlier message Heiko wrote:
>
>> As all the logging backends are fragments I excluded org.slf4j.impl
>> package from imported packages. This means you can install the
>> slf4j-api bundle in an OSGi container successfully without a backend. > Not sure whether this is what we want.
>
>
> I think it makes life easier if the slf4j-api bundle can be installed without a back-end. However, this is assuming that a desired back-end bundle can be installed and successfully bound with slf4j-api. (It is an obvious requirement but still may be useful to mention.)
>
> This version can be pulled in either from http://github.com/weiglewilczek/slf4j (master) or from http://github.com/ceki/slf4j (weiglewilczek-master).
>
> Your comments are most welcome,
>
> --
>
> Ceki
> _______________________________________________
> slf4j-dev mailing list
> slf4j-dev at qos.ch
> http://qos.ch/mailman/listinfo/slf4j-dev
>
>
>

-- 
Heiko Seeberger

Company: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net
Akka - Simpler Scalability, Fault-Tolerance, Concurrency & Remoting through
Actors: akkasource.org