A lot of the scenarios where equinox
is embedded within an application it is desired to have bundles use the
same packages which are available from what I call the "outer"
or "launching" application. For example, in server-side
equinox a web application launches equinox and serves content from bundles
installed in the running equinox instance.
In this case we want the packages provided
by the outer web container to be available for import from bundles running
in the framework (e.g. javax.servlet.http etc.). To do this the the
system.bundle must export the packages available from the outer execution
environment. This can be done by install system.bundle fragments
which export additional packages from the execution environment or by setting
the org.osgi.framework.systempackages Java property. But the only
way the framework can actually load the classes from these additional exported
packages is if the framework's classloader has access to the classloader
of the outer application.
There is a new option added to 3.3 to
specify that the current classloader should be used as the parent classloader
of the framework classloader. Setting osgi.frameworkParentClassloader=current
will set the framework's parent classloader to the same classloader which
loaded org.eclipse.equinox.launcher.Main. If you embed org.eclipse.equinox.launcher.Main
into your application then you could use this option to get the same results.
"Steven E. Harris"
<seh@xxxxxxxxx> Sent by: equinox-dev-bounces@xxxxxxxxxxx
05/09/2007 11:37 AM
Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
[equinox-dev] Re: How to use launcher.jar
Thomas Watson <tjwatson@xxxxxxxxxx> writes:
> With that said I'm not sure the equinox.launcher is well suited for
> the embedded usecase anyway. The equinox.launcher sets up its
> classloader for the osgi framework which will be inaccessible from
> your "outer" application which is embedding equinox. By
> framework classloader created by equinox.launcher uses the boot
> classloader as its parent so it will be completely disconnected from
> your applications classloader.
I don't understand the significance of the difference here. Are you
suggesting that in the "embedded" arrangement I'm using now that
application class loader can access parts of the OSGi framework? So
far the only sort of connection I've been able to establish is passing
my own "endSplashHandler" to EclipseStarter.start(). What would
missing out on with the launcher's class loader arrangement?
My motivation for looking for an alternative to the "embedded"
arrangement pertains to this problem:
How to use ext[t]ension bundle and adaptor hooks?
That is, without the launcher JAR, I can't make my program start up
properly without manually configuring the class path to include my
adaptor hook bundles. That proves to be somewhat onerous, as some
other developers -- and, eventually, users -- don't want to bother
with setting up a script to do the dirty work.
It's alluring that the launcher JAR takes care of this class path
construction automatically. In my current wrapping of EclipseStarter,
I set the EclipseStarter.PROP_EXTENSIONS property to point to my
adaptor hook JAR, but of course it's not automatically put on the
class path and hence not loaded as desired.
Steven E. Harris
equinox-dev mailing list