Sahoo's Blog

GlassFish V3 on OSGi - Part I

I guess by now you have heard the big news coming out of GlassFish community. We have put back initial code that enables GlassFish to run on an *OSGi* R4 platform. Felix is currently our default OSGi runtime. I am assuming you have either read Jerome's blog or Eduardo's posting in The Aquarium. If you have not, I suggest you read them first. Jerome and Eduardo have explained some of the rational behind this change and what to expect in coming days. Now some details not covered there:

The following picture tries to give an idea as to how the runtime looks like when GlassFish is running on an OSGi platform:

All our GlassFish modules including the Java EE APIs are packaged as OSGi bundles. Some of you may wonder what's HK2's role here. HK2 has following layers, viz:
module layer - responsible for class loading and life cycle management
component layer - which is responsible for component registration, injection, outjection, etc.
config layer - responsible for configuring components by reading data from XML file. The XML file can be transactionally updated to reflect changes in component.
A simple class diagram that shows some of the HK2 abstractions (except those of config layer) is shown below:

We have implemented HK2' module layer APIs on OSGi by delegating to OSGi module layer. HK2's component layer and config layer relies on HK2's module APIs. Once those APIs are available, it is not that difficult to make those two layers available as OSGi bundles. Except for cases like URLStreamHandler registration, GlassFish modules do not use OSGi APIs directly; they use HK2 module APIs which are available on both the runtimes. That allows them to run unchanged on both the runtimes. Some other day, I shall talk about the service mapper.

Last, but not the least, I want to thank Felix community for the excellent support that they provide in their forum. It's not just the framework that I found easy to use. Their maven-bundle-plugin, which wraps Peter Krien's bnd tool, makes life of maven users so much easier.

Now, before you ask me, let me preempt you:

Why did we take this approach?
A lot of GlassFish code was already written, so we wanted an easier migration path without disrupting our schedule.

What are the benefits of this approach?
Well, it allows us to experiment on both the modes. Theoretically, given another compatible module system, we can switch to using that with relative ease.

What are the drawbacks of this approach?
By limiting ourselves to HK2 APIs, we are not able to take advantage of rich module management APIs that OSGi provides.

Will we continue to support both the modes?
Not very long. But, that does not mean that HK2 will vanish. As Jerome explains in his blog, HK2 will continue to provide component layer and config layer.

How does GlassFish use bundle repository?
That is something I have to investigate next.

What other OSGi implementation does it run on?
Theoretically speaking, since our code is written against R4 spec, it should run in any compliant implementation - it's a matter of configuration I would say. We have tried all major three and it works. More on this to follow in time to come. Felix is currently our default platform - it is distributed as part of our runtime.

What's next?
This is just the beginning. We have so many things lined up in this area. I have a long TODO list which I have to prioritize. We hope you shall provide constructive feedback to make it better. As Eduardo mentioned in his blog, please wait for the builds to stabilize.

Comments

This work is licensed under a Creative Commons License.