Re[2]: [osgi-dev] Backward compatibility

[Peter Kriens <Pe...@aQute.biz>]

Bundles in R3 that did not import their packages were in principle
wrong; it was never the intention that you could access anything
outside your imports. However, as Richard indicated, the delegation to
the parent class loaders caused the bootclasspath to become available
and that is almost by definition not portable.

Kind regards,

     Peter Kriens


RSH> BOTTARO Andre RD-MAPS-GRE wrote:
>>  
>> Thanks for your clear answers and the hints to make the platform behaves like an R3 platform. 
>>
>> I hope that felix will be delivered with some relevant bundle repositories soon. And since my hello world bundle works on the last release of felix, I hope you will announce in which way felix is backward compatible. 
>>   

RSH> I think the biggest issue for bundles migrating from Oscar to Felix is
RSH> the strictness of R4 class visibility. Oscar automatically made classes
RSH> on the class path visible to bundles. Felix does not.

RSH> Felix is much more strict, in accordance to the R4 spec, in an effort to
RSH> achieve better bundle portability among frameworks and to allow class 
RSH> path classes to be replaced by bundles.

RSH> To resolve this issue, most R3 bundles simply have to add an 
RSH> Import-Package declaration for the packages they were previously 
RSH> accessing implicitly from the class path.

RSH> I don't think there are other significant issues with migrating, but 
RSH> perhaps other people can share their experience.

->> richard

>> Sorry for the cross-post mess.
>> --
>> André
>>
>> -----Message d'origine-----
>> De : Richard S. Hall [mailto:heavy@ungoverned.org] 
>> Envoyé : vendredi 9 mars 2007 17:10
>> À : OSGi Developer Mail List
>> Cc : felix-dev@incubator.apache.org
>> Objet : Re: [osgi-dev] Backward compatibility
>>
>> BOTTARO Andre RD-MAPS-GRE wrote:
>>   
>>> It happens that more than a year after the 4th public release of OSGi(tm) 
>>> specification and that felix project has begun, there is still an 
>>> important gap to overcome for oscar developers to adopt felix platform :
>>>
>>>     
>>
>> I am not sure why this message is cross-posted to osgi-dev, since it 
>> seems to be related to Felix. I will respond in a cross post this time, 
>> but future discussion should be divided into general OSGi discussion for 
>> osgi-dev and Felix discussion for felix-dev.
>>
>>   
>>> Backward compatibility
>>>
>>> - The numerous R3 bundles developed before are not deployable as is on 
>>> the felix platform whereas the Core specification announce that OSGi(tm) 
>>> platfroms must be backward compatible (Manifest version 1 and 2)
>>>
>>>     
>>
>> This is easier said than done, since the specs prior to R4 were not 100% 
>> clear. Some framework implementations allowed automatic access to 
>> classes on the class path and some didn't. This ambiguity led to bundles 
>> that didn't work on all platforms, which is why the R4 spec made this 
>> explicit.
>>
>>   
>>> - The felix platform is delivered with a bundle repository client 
>>> which is not compatible with previous repositories. It is due to obr 2 
>>> technical disrupt and felix decision (?) not to remain backward 
>>> compatible.
>>>
>>>     
>>
>> OBR1 and OBR2 are really only related in name and goal. They are 
>> completely different service implementations trying to do the same thing.
>>
>>   
>>> It explains that the choice between R3 and R4 before any development 
>>> phase is not easy and I admit that I sometimes recommend to stay on 
>>> the good old oscar... (especially for quick developments, quick 
>>> application tests, or developments with existing R3 bundles).
>>>
>>>     
>>
>> No one would force you to move to the R4 platform, but I can say for 
>> sure that Oscar has more spec issues than Felix.
>>
>>   
>>> Some (naive ?) solutions may answer the 2 problems I mention. Tell me 
>>> if it is reasonable:
>>> - felix Module Class Loader may enable bundles with manifest version 1 
>>> to import all the packages of the boot-delegation classpath. Or even 
>>> better, a R3 module class loader can be attached to those bundles.
>>>
>>>     
>>
>> Yes, it would be possible to have the class loader check to see if this 
>> is an "R3" bundle and delegate everything to the parent class loader 
>> first, which is how Oscar behaved. However, I feel this is not necessary 
>> for two reasons:
>>
>>    1. As I said above, not all frameworks had this behavior prior to R4,
>>       so a bundle is still not guaranteed to get the same behavior of
>>       the framework it was developed and tested on.
>>    2. You can set the org.osgi.framework.system.packages property to
>>       "*", which will then give you a similar behavior, i.e., all class
>>       loads will first be delegated to the parent class loader.
>>
>> In the end, I believe strictness is more important. You can easily run 
>> BND over your existing bundles to generate proper manifests.
>>
>> However, it is not out of the question to consider automatic parent 
>> delegation for R3 bundles, but there was a conscious decision not to do 
>> this with the belief that it caused more problems that it solved. We can 
>> discuss this issue on felix-dev.
>>
>>   
>>> - oscar bundle repository client may be embedded in the felix one in 
>>> order for the latter to be backward compatible. (on this simpler 
>>> topic, I could recommend using felix with kf bundle repository client 
>>> and server...)
>>>
>>>     
>>
>> The OBR1 bundle should run on Felix except for perhaps a missing 
>> Import-Package statement for org.osgi.framework, which can be added (or 
>> worse you could use the system packages property).
>>
>>   
>>> I did not check if other platforms treat R3 bundles better. Was the 
>>> core specification too ambitious ?
>>>
>>>     
>>
>> In short, no.
>>
>> -> richard
>>   

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