[slf4j-dev] OSGi support in slf4j

[Heiko Seeberger]

Hi Hugues,

Thanks a lot for your attention!

Not sure, but as far as I understand, you probably got something wrong
regarding the uses directive: There is no version! The only piece of
information that is given is that an exported package "uses" some
other packages, e.g. org.slf4j.scala uses types from scala.*. Only the
packages, no versions. But that's enough to  enable the OSGi container
to make a consistent classpath. I know that this is an advanced topic,
but it is a really important one. There are good examples in the OSGi
spec.

Regarding Scala's binary compatibility issues the uses directive is
very important. And it is helpful in a lot of cases. There are almost
no cases where it causes trouble. Therefore I suggest to use it.

Heiko

On Wednesday, September 15, 2010, Hugues Malphettes
<hmalphettes at intalio.com> wrote:
> Hi Heiko,
>
> Thanks for all the good work on scala and looking in depth into slf4j in OSGi.
>
>> There is no uses directive for the exported packages. Well, that cannot be
>> done manually (see Maven Bundle plugin above)
> I am not convinced that the use directive is necessary for slf4j.
> I have not seen a situation for slf4j where the use directive will
> solve an actual problem.
> I am afraid that the use directive automatically generated by BND will
> reflect in the bundle the version of the various jars used during the
> build: not new constraints that we did not identify and expressed in
> the manifest already.
>
> In my experience, I had to relax the use directive in some manifests
> generated by BND.
> The use directive would specify that it only works with a different
> version of a library.
> In fact it just meant that it was built with a newer version of a
> library than the one imposed to my environment.
>
> The most common case is for packages provided by the JDK such as javax.xml.
> A BND generated manifest compiled with a specific stax version on the
> class path will specify in its use directive that it requires
> javax.xml with a version number.
> Another library would be compiled with jdk6 instead. BND will then
> specify that this particular package uses the version "0" of
> javax.xml.
> At runtime OSGi will refuse to load in the same class-space those 2
> libraries because both of them rely on different and incompatible
> versions of javax.xml
> Relaxing the manifest of those bundles by removing the use-directive
> has been the best solution I found so far.
>
> Thanks for your attention,
> Hugues
>
> On Wed, Sep 15, 2010 at 12:03 AM, Heiko Seeberger
> <heiko.seeberger at googlemail.com> wrote:
>> Hi,
>> My recent changes to the POM of the slf4j-scala-api module show how we
>> should IMHO be doing OSGi in every module: Don't write the whole manifest
>> manually, but let the Maven Bundle plugin generate it.
>> Looking at the manifest of slf4j-api there are several issues:
>>
>> There is no Bundle-Version
>> The bundle symbolic name does not follow "well recognized OSGi conventions":
>> It should follow the reverse domain naming convention, i.e. org.slf4j.api
>> I guess that SLF4J is compiled to target 1.5. At least for the JUL module it
>> has to be 1.4 at minimum. Therefore I doubt that the 1.3 execution
>> environment ist the correct setting
>> I think the import for org.slf4j.impl should be optional, but I have to play
>> with that one
>> There is no uses directive for the exported packages. Well, that cannot be
>> done manually (see Maven Bundle plugin above)
>>
>> I suggest I give it a try and change the slf4j-api module to also use the
>> Maven Bundle plugin. Thoughts?
>> Heiko
>>
>> 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
>>
> _______________________________________________
> 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