[slf4j-dev] State of OSGi & SLF4J

[John E. Conlon]

Ceki Gülcü wrote:
> Hello all,
>
> Using the latest SLF4J code from the repo (rev. 752), I am able to
> start both the slf4j-api and slf4j-simple bundles. Just as
> importantly, the slf4j-api bundle successfully exports the "org.slf4j" package.
>
> The MANIFEST.MF file for slf4j-api reads:
>
> Implementation-Title: slf4j-api
> Bundle-ManifestVersion: 2
> Bundle-SymbolicName: slf4j.api
> Bundle-Name: slf4j-api
> Bundle-Vendor: SLF4J.ORG
> Export-Package: org.slf4j;version=1.3, org.slf4j.spi;version=1.3, 
> org.slf4j.helpers;version=1.3
> Import-Package: org.slf4j.impl
>
> The MANIFEST.MF file for slf4j-simple reads:
>
> Implementation-Title: slf4j-simple
> Bundle-ManifestVersion: 2
> Bundle-SymbolicName: slf4j.simple
> Bundle-Name: slf4j-simple
> Bundle-Vendor: SLF4J.ORG
> Require-Bundle: slf4j.api
> Export-Package: org.slf4j.impl
> Import-Package: org.slf4j, org.slf4j.spi, org.slf4j.helpers
>
>
> There is none of the "partial=true;mandatory:=partial" crap we had
> previously.
>
>   
"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.


kind regards,
John