equinox-dev-bounces@xxxxxxxxxxx [mailto:equinox-dev-bounces@xxxxxxxxxxx] On Behalf Of Thomas Watson
Sent: Thursday, February 01, 2007
To: Equinox development mailing
Subject: RE: [equinox-dev] Bundle
wrote on 02/01/2007 01:22:27 PM:
>> Please refer to my
>> Rick Litton
There are a few reasons we package the core org.osgi classes in the
framework implementation (org.eclipse.osgi)
1) Packaging convenience. Having all the org.osgi.* classes
packaged directly in the framework implementation reduces the amount
jars you need to find and place on the classpath of the framework.
-> I was assuming that the osgi bundles will be auto-started and
that the required packages are exported which can then be imported
by org.eclipse.osgi. I haven’t actually done this but I think it
> The OSGi framework is not
loaded with an OSGi classloader. It has no
> ability to reach out into a
bundle to load classes via Import-Package.
> Especially core classes in
the org.osgi.framework package that are needed
> to implement the Framework
Which is true. It’s the
chicken and egg scenario and causes problems with a mixed framework
(e.g. mixing Equinox and Felix)
scenario. I was actually looking for a mix and match solution if it was
2) Technically we need to modify some of the classes provided by the
OSGi Alliance to hook into our implementation. For example,
FrameworkUtil, AdminPermission and BundleSignerCondition.
>> -> Can we get away
with just extending the osgi interfaces? I guess
I find changing someone else’s framework classes/interfaces unappealing.
> The OSGi specification states
that implementations are free to modify
> the OSGi classes to hook in
to their implementation. We cannot
> simply extend classes like
FrameworkUtil because that is the class
> that other bundles will
reference, not our extending class. That
> would create a containerism.
It’s actually the focus of another
project I’m currently working on (outside of work). Creating a
that allows for a “shell-like”
environment that encapsulates components from different
frameworks seems to be a possible solution.
> Felix project is also
packing the org.osgi packages in the felix
> framework for the same
Yes, again this is true.
Classloading is a major problem with OSGi framework
Implementations and I wonder if what you
mentioned as an “OSGi classloader”
is a feasible approach. Has anyone
ventured into this?
3) Working on future reference implementations for the OSGi
We need the ability to modify the API with enhancements
that will become available in future public OSGi specifications.
For example, we are currently working on the Reference
Implementation for OSGi R4.1 which introduces a small number new methods.
>> -> Personally, I
think that this is even an important consideration.
Switching OSGi R4 bundles with OSGi R4.1 ones will be a “snap”
(hopefully) when they become available. Like everyone else, I
suppose OSGi will also provide maintenance or versioned releases to
fix defects, etc. It would be expedient to simply switch to those
versioned ones without having to release an Equinox distro in
response. In this sense, tight coupling has its disadvantages in my view.
> We cannot treat these core
classes as a real bundle, I can see some value
> in having the jar separate
from the org.eclipse.osgi jar but it adds
> complication when launching
the framework because you need to find an
> osgi.jar that is compatible
with the framework implementation.
This certainly is a problem especially
since OSGi allows for modifying core classes. But
we are putting our thinking hats on to
possibly get around this (we hope).
Thanks for the info.