[slf4j-dev] OSGi support in slf4j

[Hugues Malphettes]

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
>