Re: [equinox-dev] Embedding Equinox OSGi and EclipseStarter

[Jason Sankey <jason@xxxxxxxxxx>]

Hi Alex,

My responses inline.

Alex Blewitt wrote:
> I've been playing around with embedding the OSGi/Equinox platform into
> an existing Java system (as opposed to the other way around). I'm
> using the EclipseStarter to bring up the framework, and once it's up
> and running with the bundles it works like a charm. I can start up a
> remote console and reconfigure it if necessary etc.

This is exactly what we are doing at the moment (i.e. embedding Equinox).

> What I'd really like to do is give some control over to the Java
> system that contains it, particularly with reference to installing new
> bundles, starting and stopping existing bundles and so forth. All I'd
> need to do is get hold of a suitable BundleContext and I should be
> able to do this.
>
> Unfortunately, there doesn't seem to be any way of getting this back
> from an EclipseStarter. I could duplicate the code but it seems
> somewhat wasteful; there's an OSGi instance in EclipseStarter that has
> a getBundleContext() that would probably do me, if it weren't for the
> fact that OSGi is a private field of EclipseStarter.

How are you starting the framework?  We use EclipseStarter.startup, 
which returns the BundleContext from the static OSGi instance.  This 
sounds like exactly what you need.

> I'm wondering whether you think it's a good idea to add something like
> this to EclipseStarter:
>
> public static BundleContext getSystemBundleContext() {
>  return osgi.getBundleContext();
> }

This addition probably also wouldn't hurt.

> I'd then be able to use that to stop/start the various bundles,
> install others etc. Of course, whilst I can do this via the console, I
> really want to have a programmatic hook up to make it work. And no, I
> can't refactor the old system to be a bundle of the Equinox runtime;
> this is strictly a subset of an existing system.

Yep, we use this context to (un)install and start bundles from our own 
PluginManager.

> I note that other places do this kind of thing e.g. the servlet
> bridge, which maps a URL onto commands that get processed. I'm
> wondering if the direct way has some obvious flaw that I'm missing?


Hope that helps,
Jason

--
Jason Sankey
http://zutubi.com/