http://bugzilla.slf4j.org/show_bug.cgi?id=75 Gunnar Wagenknecht <gunnar@wagenknecht.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gunnar@wagenknecht.org --- Comment #14 from Gunnar Wagenknecht <gunnar@wagenknecht.org> 2009-12-04 10:15:26 --- 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. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.