Monday, May 09, 2011

Equinox digraph ready for use

Previously I described how Virgo used OSGi framework hooks to implement a directed graph, or digraph, of isolated groups of bundles known as regions. The region digraph has now moved to Equinox and I'm modifying Virgo to use the Equinox region digraph in place of Virgo's own (see bug 343364 for details).

I always prefer making such changes in an incremental way, so the first step was to add the Equinox region digraph bundle to the Virgo kernel without exploiting it. The Virgo kernel runs fine with the Equinox region digraph in situ. This is because the Equinox digraph adds all bundles to its kernel region and so provides no isolation between those bundles. Later, Virgo's region digraph partitions the bundles in Virgo kernel and Virgo user regions with appropriate isolation and things continue to work as normal.

This is interesting, but not particularly useful. The whole point of the region digraph abstraction was to make it easy for multiple parties wishing to provide isolation via the OSGi framework hooks to be able to collaborate together by sharing and manipulating a single region digraph. It was never intended that multiple digraphs should co-exist.

But there is a useful point here. If you have an Equinox-based system, of which there are many, you can introduce the Equinox digraph with zero functional impact. All your bundles, including those installed before and after the Equinox region bundle, go in the Equinox kernel region and there is no isolation between those bundles.

When you want to start exploiting the digraph, you can use the RegionDigraph service to create a new region, attach it with appropriate filters, if any, to and from the kernel region, and then install a bundle into the new region using the Region.installBundle operation. After starting this bundle, you will then have a bundle context that can be used to install further bundles into the new region using the OSGi standard BundleContext API.

I hope this will inspire you to have a go at using the Equinox region digraph if you are an Equinox user and need to isolate groups of bundles.

Meanwhile, the standardisation of multi-bundle applications, including isolation, continues in the OSGi Alliance and a public draft of this spec should be available in the not too distant future. I hope the Equinox region digraph will be used more widely and this will help to provide feedback on the spec work.

10 comments:

Robert Sauer said...

I finally got the time to integrate region management into our runtime, and it is working just perfectly. We're using this essentially for a fully multi-tenant plugin system to Web applications. Thanks again for sharing this piece of work and especially for offering it as a separately consumable feature.

Robert

Glyn said...

Great to hear. Thanks for the feedback.

Unknown said...

I tried to use this feature in our system which use Axis2 Services also. The region separation works fine.
But when I install a bundle in another region which don't have all other kernel bundles included and define a filter with all visible name spaces, the bundle works fine without any problem. But I was not able to get the bundle events which I need to initiate Axis2 services from the kernel region. But it gives the events when I install all the bundles in one region. It would be great if I get to know where I'm missing.

Hareesh

Unknown said...

I have used this feature to use in our system which using Axis2 services also. It works fine. :)
When I install a bundle out of kernel region with filters defined with all allowed namespace, the bundle getting started fine and working. I need to get the events in that region to initiate the Axis2 services from that new bundle. I was not able to get bundle events from a different region to the kernel region or the framework. But when I install the same bundle in the kernel region, it works fine. It would be great if I find where I'm missing.

Hareesan

Glyn said...

@Hareesh - have you tried registering your bundle listener using the system bundle's bundle context, e.g. using the systemBundleContext.addBundleListener(...)?

Unknown said...

Hi Gyln,
I tried adding event listener. But the bundleChanged method is not get called when a bundle is installed or started.
For example, I'm creating a calss BundleEventListener which implements BundleListener and initializing that class and adding that using BundleContext.addBundleListener().

In my context, I need to install the bundles with an event received from the framework which will invoke a method where I need to write the logic. So I'm using a singleton pattern java class to pass the bundle context from start method to the relevant method.

I couldn't find where I'm missing here.

Glyn said...

Which bundle's BundleContext did you use?

Unknown said...

The bundle context I'm getting from the start method of a bundle.

Glyn said...

I suggested above that you use the BundleContext of the system bundle. If bc is your BundleContext, you can safely get the system bundle's context:

bc.getBundle(0L).getBundleContext()

Unknown said...

Thanks for you information. :)

Projects

OSGi (130) Virgo (59) Eclipse (10) Equinox (9) dm Server (8) Felix (4) WebSphere (3) Aries (2) GlassFish (2) JBoss (1) Newton (1) WebLogic (1)