[slf4j-dev] [Bug 75] Cyclic dependency in OSGi

[bugzilla-daemon at pixie.qos.ch]

http://bugzilla.slf4j.org/show_bug.cgi?id=75





--- Comment #16 from Gunnar Wagenknecht <gunnar at 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/java/org/slf4j/impl/

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.