[slf4j-dev] [Bug 75] Cyclic dependency in OSGi

[bugzilla-daemon at pixie.qos.ch]

http://bugzilla.slf4j.org/show_bug.cgi?id=75





--- Comment #17 from Hugues Malphettes <hmalphettes at 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/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.