You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by BOTTARO Andre RD-MAPS-GRE <an...@orange-ftgroup.com> on 2007/03/09 09:43:31 UTC
Backward compatibility
Hi,
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 :
- 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)
- 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.
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).
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.
- 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...)
I did not check if other platforms treat R3 bundles better. Was the core specification too ambitious ?
--
André
Re: Backward compatibility
Posted by Rob Walker <ro...@ascert.com>.
We've just migrated our "main" application from Oscar to Felix.
It did take us some time, and there were a few areas of "detail" we had
to be careful of, but we're up and running now and Felix is doing a very
very good job for us.
We used mangen to deal with Manifest differences automatically - a
simple config switch tells it to process our bundle set and generate v2
manifests rather than v1 (our manifest generation is fully automated in
our build process).
That aside, a few minor tweaks and a custom MutablePropertyResolver to
make our property files work same in Felix as they did under Oscar, and
we're up and running.
Just out experiences
-- Rob
BOTTARO Andre RD-MAPS-GRE wrote:
> Hi,
>
> 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 :
> - 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)
> - 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.
>
> 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).
>
> 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.
> - 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...)
>
> I did not check if other platforms treat R3 bundles better. Was the core specification too ambitious ?
>
> --
> André
>
>
--
Ascert - Taking systems to the Edge
robw@ascert.com
+44 (0)20 7488 3470
www.ascert.com
Re: [osgi-dev] Backward compatibility
Posted by "Richard S. Hall" <he...@ungoverned.org>.
BOTTARO Andre RD-MAPS-GRE wrote:
>
> It happens that more than a year after the 4th public release of OSGi™
> 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™
> 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
Re: [osgi-dev] Backward compatibility
Posted by ChangWoo Jung <ju...@kr.ibm.com>.
Bottaro,
AFAIK, running R3 bundles on Equinox seems okay.
I guess you are dealing with OBR deployment side of story. I mean osgi
client with obr repository, right?
I am not the Felix guy though... but have some experience with using OBR2.
Wouldn't be possible to regenerate the meta information (repository.xml)
at server side using OBR2 format against existing R3 bundles?
I guess it will work with bindex which you can get it from osgi site.
I also found serval things before...
- OBR2 bundle dislike the situation that if the bundle doesn't have
symbolic name. But I guess it could be easily changed, if there is no
symbolic-name then use Bundle-Name instead since all R3 bundle has.
- The packages from org.osgi.framework.system.packages has to be added to
SystemPackages's capability.
After that I manage to run existing R3 bundles as well. Actually I used
Equinox and OBR repository(OBR2). But honestly I haven't used Felix as
client osgi.
ChangWoo Jung
Staff R&D Engineer
Ubiquitous Computing Laboratory, IBM Corporation
+82-2-3781-8422 (t/l: 825-8422)s
jungcw@kr.ibm.com
"BOTTARO Andre RD-MAPS-GRE" <an...@orange-ftgroup.com>
Sent by: osgi-dev-bounces@www2.osgi.org
2007-03-09 오후 05:43
Please respond to
OSGi Developer Mail List <os...@www2.osgi.org>
To
<fe...@incubator.apache.org>, "OSGi Developer Mail List"
<os...@www2.osgi.org>, "OSGi Developer Mail List"
<os...@bundles.osgi.org>, <os...@incubator.apache.org>
cc
Subject
[osgi-dev] Backward compatibility
Hi,
It happens that more than a year after the 4th public release of OSGi™
specification and that felix project has begun, there is still an
important gap to overcome for oscar developers to adopt felix platform :
- The numerous R3 bundles developed before are not deployable as is on the
felix platform whereas the Core specification announce that OSGi™
platfroms must be backward compatible (Manifest version 1 and 2)
- 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.
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).
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.
- 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...)
I did not check if other platforms treat R3 bundles better. Was the core
specification too ambitious ?
--
André _______________________________________________
OSGi Developer Mail List
osgi-dev@www2.osgi.org
http://www2.osgi.org/mailman/listinfo/osgi-dev