[slf4j-dev] State of OSGi & SLF4J

[John E. Conlon]

Ceki Gülcü wrote:
>
> At 11:21 PM 2/22/2007, John E. Conlon wrote:
>   
>> "Crap" is necessary to prevent client bundles that import the org.slf4j
>> package from being 'wired' by the OSGi runtime classloader matrix to the
>> slf4j-api bundle.  Clients wired to this bundle will get
>> ClassNotFoundExceptions when they try to use get a logger.  This is
>> because its packages org.sl4fj and org.slf4j.impl are 'split' across the
>> api and the binding bundle.  It will look okay as long as no bundle
>> tries to load any classes.
>>
>> As soon as I can build the trunk I will adjust latest metadata to
>> accommodate the split packages and preform the OSGi profile tests.
>>     
>
> I meant no offense with the term "crap". Regardless, I should have
> used more appropriate terminology.
>   
No offense taken.
My misunderstanding.  See below.
> Anyway, I was referring to section 3.13.2 (page 68) of the OSGi Core
> specification. According to my very limited understanding, the use
> "Require-Bundle" keyword is discouraged. In particular, the use of
> "partial=true;mandatory:=partial" which SLF4J no longer needs, as it no
> longer has split packages. I use the term split package as defined in
> the specification (page 68):
>
>    Split Packages: Classes from the same package can come from
>    different bundles with Require bundle, such a package is called a
>    split package.  Split packages have the following drawbacks:
>    ...
>
>   
Your right - crap.
> You seem to think that SLF4J has split packages. 
Yes I thought so because the binding projects manifests still contain 
Require-Bundle: slf4j.api.  

But after your pointing it out, only now do I remember  that bit of 
fancy deletion going on in the jar plugin. 
So I checked out the slf4j-api.jar and Hey NO split packages! Very nice.

> We used to but I
> don't think that is still the case. All required classes in org.slf4j
> are packaged within slf4j-api.jar and all required classes in
> org.slf4j.impl are package within slf4j-xxx.jar where xxx stands for a
> given binding.
>
> What am I overlooking?
>   
No it was I that was overlooking the big picture. 

On the other hand there are some issues of tuning of  metadata to add 
versioning to exports and version ranges back to the imports.  These I 
think are needed to pass the OSGi tests we have set up and in production 
environments to make sure we don't commingle with previous releases 
running in the OSGi runtime.

Would you like me to reintroduce these?
> Wishing you a nice weekend,
>
>   
Likewise,

John