Peter,

That would be the best solution for us :). I didn't mention that case as it's unknown to me who and to what degree current implementations would be impacted. Does anyone here have an implementation based on the RFC, and if so would this change be possible and agreeable?

thanks
ken



On Dec 17, 2007, at 6:34 AM, Peter Kriens wrote:

Maybe the solution is to change the Resource API to return a string
instead of a Version object. When we made that API it did not look
like R3 was having much life after R4 but Concierge seems to make some
inroads.

Kind regards,

     Peter Kriens

KG> Hello ~

KG>    I'm working on implementing OBR (RFC-0112) on Concierge, an R3
KG> framework. The R4 class org.osgi.framework.Version is part of the
KG> implementation.  In my current setup I'm referencing all
KG> org.osgi.framework.* classes from the R3 OSGi.jar bundle. In the R3 KG> spec in section 4.4 it is stated "...the Framework must ensure that
KG> all import-
KG> ers of a class in an exported package use the same classloader to load
KG> that
KG> class or interface." If I add my own Version class in another bundle KG> it is not resolved by client bundles. Assuming this is the reason, my
KG> strategy going forward could be:

KG> 1. Modify the interfaces such that my Version class uses a different
KG> namespace.
KG> 2. Backport Version into the R3 OSGi jar used in my runtime environment.
KG> 3. Build a custom OBR-like system for our R3 runtime.

KG>    None of these solutions really appeal to me as each one has
KG> significant negatives.  Is there something I'm missing?  Any other
KG> suggestions?

KG> Thanks in advance,
KG> ken

KG> _______________________________________________
KG> OSGi Developer Mail List
KG> [email protected]
KG> http://www2.osgi.org/mailman/listinfo/osgi-dev

--
Peter Kriens                              Tel +33467542167
9C, Avenue St. Drézéry                    AOL,Yahoo: pkriens
34160 Beaulieu, France                    ICQ 255570717
Skype pkriens                             Fax +1 8153772599



_______________________________________________
OSGi Developer Mail List
[email protected]
http://www2.osgi.org/mailman/listinfo/osgi-dev

Reply via email to