felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: [osgi-dev] Backward compatibility
Date Fri, 09 Mar 2007 19:54:52 GMT
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. 
>   

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

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

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

I don't think there are other significant issues with migrating, but 
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
>   

Mime
View raw message