[slf4j-dev] [Bug 75] Cyclic dependency in OSGi
bugzilla-daemon at pixie.qos.ch
bugzilla-daemon at pixie.qos.ch
Fri Dec 4 10:15:28 CET 2009
http://bugzilla.slf4j.org/show_bug.cgi?id=75
Gunnar Wagenknecht <gunnar at wagenknecht.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |gunnar at wagenknecht.org
--- Comment #14 from Gunnar Wagenknecht <gunnar at 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.
More information about the slf4j-dev
mailing list