http://bugzilla.slf4j.org/show_bug.cgi?id=75 --- Comment #16 from Gunnar Wagenknecht <gunnar@wagenknecht.org> 2009-12-04 20:49:31 --- (In reply to comment #15)

Here is a fragment that supports pluggable slf4j implementations: http://github.com/hmalphettes/slf4j/tree/osgi-binder/slf4j-api-osgi/src/main...

Thanks for the link. I had a quick look and I have some comments/questions. It looks like you simple use the PackageAdmin to look for anything that exports the "impl" package. I don't think that this "magic" is the best approach. One reason is that it forces implementors to export internal implementation. Note, in OSGi it's actually considered good style not to export internal implementation. Another thing is that I think you'll need re-implement a lot of logic around handling package wiring, etc. For example, what happens if two different SLF4J API versions are installed? Mind you, in OSGi this is possible.

slf4j implementations would be packaged as bundles and slf4j-api would not import the org.slf4j.impl package.

If we are really going to provide an OSGi integrator bundle which depends on OSGi API I propose to use OSGi services. API providers would simply export the "impl" as an OSGi service. The OSGi integrator bundle would watch for those services. OSGi takes care of proper resolution, conditions/permissions, service ranking, etc.

But managing bundles is certainly nicer than managing fragments so maybe that is a good approach?

It boils down to what's really necessary. IMHO the fragment approach works very well. Of course, it has some limitations but other than dealing with manifests it doesn't introduce any dependencies on OSGi APIs. Additionally, from an SLF4J point of you nothing changes, i.e. everything is loaded by the same ClassLoader and bound to the same lifecycle (of the SLF4J API bundle). It's just that the "impl" package shouldn't be exported by the API bundle but contained in a fragment. Additionally, fragments allow for tight coupling to a specific hosts. This may make versioning less error prone because the fragment only resolves if it can be bound to the right SLF4J API host. In contrast - if you really want the full benefits of OSGi, then the fragment approach should be dropped. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.