[Bug 75] Cyclic dependency in OSGi

http://bugzilla.slf4j.org/show_bug.cgi?id=75 --- Comment #15 from Hugues Malphettes <hmalphettes@intalio.com> 2009-12-04 19:28:47 --- (In reply to comment #14)
FWIW, in the Eclipse Orbit repository we also provide an SLF4J API bundle. This bundle follows the fragment approach which a small difference. The SLF4J API bundle neither imports nor exports the "impl" package. The "impl" package has to be provided by a fragment. It's also not exported because it's not API. Others (except SLF4J) should not be able to import the "impl" package.
BTW, fragments can happily consume services simply by using FrameworkUtil to get access to the BundleContext of the SLF4J bundle. In Gyrex we provide a native SLF4J implementation which delegates to the OSGi LogService.
I also don't think that there will be a one-fits-all approach. I could imagine that there will be native OSGi SLF4J logger which doesn't delegate to the LogService but which extends SLF4J logger discover to use the OSGi service registry for discovering logger implementations. This might allow for the greatest flexibility (eg. switching logger implementations at runtime, maybe even use different logger implementations per thread/bundle, etc). However, I'm not sure if such flexibility is necessary for the majority of systems out there today.
Hi Gunnar and thanks for the update. I believe Ceki's goal is to choose the solution that fits as many as possible so that eclipse and other consumers don't need to re-package slf4j. Here is a fragment that supports pluggable slf4j implementations: http://github.com/hmalphettes/slf4j/tree/osgi-binder/slf4j-api-osgi/src/main... slf4j implementations would be packaged as bundles and slf4j-api would not import the org.slf4j.impl package. This was done as a small experiment: http://github.com/hmalphettes/slf4j/blob/osgi-binder/README.txt and we agree that pluggable implementations is really not a mainstream production scenario. But managing bundles is certainly nicer than managing fragments so maybe that is a good approach? -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
participants (1)
-
bugzilla-daemon@pixie.qos.ch