[slf4j-dev] OSGi support in slf4j

[Hugues Malphettes]

>> I'm on IRC freenode #slf4j if this type of communication helps.
>
> Thanks for the offer. I don't think I'll hang around that irc channel (or
> any other irc channel), but appreciate the offer nonetheless.
Sorry for the confusion.
I meant #qos.ch as mentioned on http://logback.qos.ch/mailinglist.html
Cheers,
Hugues

On Wed, Sep 15, 2010 at 10:07 PM, Ceki Gülcü <ceki at qos.ch> wrote:
> On 15/09/2010 11:30 PM, Hugues Malphettes wrote:
>>
>> As a general answer: let's try with BND and review carefully the
>> generated manifests.
>>
>> On Wed, Sep 15, 2010 at 1:40 PM, Ceki Gülcü<ceki at qos.ch>  wrote:
>>>
>>> On 15/09/2010 9:03 AM, Heiko Seeberger 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 pom.xml does actually insert a Bundle-Version
>> I downloaded
>> http://repo1.maven.org/maven2/org/slf4j/slf4j-api/1.6.1/slf4j-api-1.6.1.jar
>> and verified that it is there.
>> The pom.xml is customized to insert the Bundle-Version without using
>> BND. Certainly a bit unusual but it does the job.
>>
>>>>    * The bundle symbolic name does not follow "well recognized OSGi
>>>>      conventions": It should follow the reverse domain naming
>>>>      convention, i.e. org.slf4j.api
>>>
>>> Wouldn't this cause other bundles expecting the current symbolic name to
>>> fail?
>>
>> Yes it would make them fail.
>> The best practice for consumer bundles is to use the Import-Package
>> directive so that they don't depend on the naming of the bundle
>> itself.
>> So it all depends how many of the consumers of slf4j-api are following
>> the best practice or using Require-Bundle.
>>
>> If that makes a difference: the re-packaging of slf4j on eclipse-orbit
>> is following the best practice mentioned by Heiko:
>> http://download.eclipse.org/tools/orbit/downloads/drops/S20100831105311/
>>
>> If it was just me: I would say +1 for following the reverse domain naming.
>
> Ok, then. Let's do it.
>
>>>
>>>>    * 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
>>>
>>> SLF4J targets JDK 1.4.
>>
>> Yes we should update that entry of the manifest.
>
> Ack (short for acknowledge).
>
>>>>    * I think the import for org.slf4j.impl should be optional, but I
>>>>      have to play with that one
>>>
>>> Hugues spent some time to tweak the manifests. I'd seek his input.
>>
>> We spent quite some time looking into getting rid of the cyclic
>> dependency between slf4j-api and its implementation.
>> http://bugzilla.slf4j.org/show_bug.cgi?id=75
>>
>> Gunnar went with the fragment approach on eclipse orbit:
>> http://bugzilla.slf4j.org/show_bug.cgi?id=75#c16 It is my favorite
>> approach so far.
>> I had done a funny experiment to wire the implementation to the API
>> dynamically. Frankly I would not use that: it is too much complexity
>> for no good reason. We could also use a Dynamic-Import.
>> If one of us has the need and the time we could develop something OSGi
>> specific to be able to plug and unplug slf4j implementations
>> dynamically.
>
> I guess such functionality targets applications which can never ever be
> stopped. Changing logging frameworks is something one does very few times
> (if ever) during the lifetime of an application and on those occasions you
> stop, update and restart the running instances.
>
>> If I remember well the import is not marked as optional because the
>> bundle does not work unless there is in fact a bundle that provides
>> the org.slf4j.impl package. I don't have a strong argument to decide
>> whether it should be optional or not.
>>
>>>
>>>>    * There is no uses directive for the exported packages. Well, that
>>>>      cannot be done manually (see Maven Bundle plugin above)
>>
>> Let's look at what is generated by BND.
>
> OK, let's give BND a shot.
>
>> I'm on IRC freenode #slf4j if this type of communication helps.
>
> Thanks for the offer. I don't think I'll hang around that irc channel (or
> any other irc channel), but appreciate the offer nonetheless.
>
> --
> Ceki
> _______________________________________________
> slf4j-dev mailing list
> slf4j-dev at qos.ch
> http://qos.ch/mailman/listinfo/slf4j-dev
>