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
