http://bugzilla.slf4j.org/show_bug.cgi?id=75 --- Comment #17 from Hugues Malphettes <hmalphettes@intalio.com> 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... 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.