http://bugzilla.slf4j.org/show_bug.cgi?id=75
--- Comment #17 from Hugues Malphettes <[email protected]> 2009-12-04 21:14:35 --- (In reply to comment #16) > > 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. Agreed: in fact it behaves in that situation just like slf4j outside of OSGi: a warning and it picks the first one. (not sure it is coded that way yet...) > > > 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. ... > > In contrast - if you really want the full benefits of OSGi, then the fragment > approach should be dropped. > The prototype really was just about solving this bug with thse constraints: - no impact on slf4j-api - no impact on the slf4j-impls as packaged today. The approach gives some kind of dynamic support to plug slf4j implementations but it remains brittle. The extra complexity is limited to those 4 classes and it happens to work with all bundles built by slf4j and logback. The PackageAdmin hack is an extender pattern (http://www.aqute.biz/Snippets/Extender) based on the Import-Package header. Using an actual OSGi service would be a lot cleaner and would give enough room to use all of OSGi benefits. So: - the Static*Binder classes http://github.com/hmalphettes/slf4j/tree/osgi-binder/slf4j-api-osgi/src/main/java/org/slf4j/impl/ will look similar - we will need to modify the slf4j implementations to declare that they provide the service. If someone has a good idea of what the service should look like, I am interested in giving it a shot. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. _______________________________________________ slf4j-dev mailing list [email protected] http://qos.ch/mailman/listinfo/slf4j-dev
