OSGi [1] has certainly seen a lot of engagement in the weeks leading up to JavaOne 2008 [2]. Jerome Dochez [3], the GlassFish [4] architect and a Principal Engineer at Sun, tells us about how it fits in with GlassFish.
Hi Jerome, what've you been up to recently?
I have been very busy in the last 18 months planning and implementing GlassFish V3, which will be the next major release of our application server. My tasks usually involve technical design of the product, implementing its core parts, and sharing the vision of an integrated yet extensible application server.
GlassFish has been undergoing a lot of development. Can you quickly hit the high points for us?
Yes GlassFish v3 is indeed breaking from previous versions by adding support for the following features:
And now... OSGi too! What's the background?
Well, we started with our own module subsystem, HK2, which I designed to allow for a certain independence with the underlying module subsystem. So, for instance, we now support running in three modes: OSGi mode (which is the default), HK2 mode, or a non modular mode, where we load all the JARs in a single class loader, which is interesting for embedability, and we can switch between these modes without changing a line of code.
We wanted to have OSGi support, because it's clearly the leading solution for modules, and it is important for GlassFish to be able to consume OSGi services directly. We also offer the OSGi services and APIs to modules and applications running in v3 so that applications do not have to necessarily constrain themselves to the traditional Java EE modules (WAR, EAR, etc..) but can leverage OSGi as a programming model too.
What are the benefits of OSGi for GlassFish?
Too early to say exactly, but clearly we like the features of the module description and package dependencies mechanism. As a tool to implement a modular application, OSGi is quite complete and the benefits of providing such facilities to applications will soon allow new converged applications, consisting of Java EE, OSGi and random libraries, to be widely used.
What about JSR-277?
JSR 277 is becoming more friendly to OSGi as well. My role as an influencer would be to continue pushing the best integration possible between the technologies. I really believe that a good module subsystem should be implemented at the JVM level. I understand that OSGi has to work within the boundaries of the JDK features that had it has access to, but I think there is plenty of opportunity to bring the communities together and provide users with a solid compatible set of features that will preserve their investments.
Can we hear more about all this at JavaOne?
Yes. There will be a short demo during Bob Brewin's keynote on Tuesday afternoon. After that, at 4.40, there is a session on GlassFish V3 where we will demonstrate its extensibility and embeddability. That same day, in the evening, (if I am still alive) there a BOF where we encourage attendees to come and share informal discussions around GlassFish.
My email is jerome.dochez@sun.com, anyone attending JavaOne is welcome to request a meeting with me, I will be there all week and am more than happy to spend time with interested parties.
| Attachment | Size |
|---|---|
| jerome.jpg [5] | 7.79 KB |
Links:
[1] http://www.osgi.org/Main/HomePage
[2] http://java.sun.com/javaone/sf/index.jsp
[3] http://blogs.sun.com/dochez/
[4] https://glassfish.dev.java.net/
[5] http://osgi.dzone.com/sites/all/files/jerome.jpg