[slf4j-dev] OSGi support in slf4j

Hugues Malphettes hmalphettes at intalio.com
Tue Nov 2 23:27:41 CET 2010


On Tue, Nov 2, 2010 at 2:43 PM, Heiko Seeberger <
heiko.seeberger at googlemail.com> wrote:

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

That would be the one thing I would change.
Thanks Heiko!
Hugues



>
> 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
> _______________________________________________
> slf4j-dev mailing list
> slf4j-dev at qos.ch
> http://qos.ch/mailman/listinfo/slf4j-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://qos.ch/pipermail/slf4j-dev/attachments/20101102/46d025f0/attachment-0001.html>


More information about the slf4j-dev mailing list