[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Embedding Equinox OSGi and EclipseStarter

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 Sankey