Skip to main content

The Remedy

Posted by editor on May 23, 2008 at 7:30 AM PDT

The increasing prominence of OSGi

Let me admit something: I don't get OSGi. I'm not saying I don't like it, I just don't really understand what it is or why it matters so much. The Wikipedia article isn't much help either, so over the past few months, I've been quietly nodding my head in seeming agreement as OSGi-related posts show up with increasing frequency among our weblogs. Back in April, Mandy Chung blogged about JSR 277 and OSGi interoperability and Supporting OSGi Bundles in the Java Module System (which kind of sound like the same thing, right?), along with Sahoo announcing you can run GlassFish V3 on OSGi, and Jean-François Arcand spoke at JavaOne about Grizzly's OSGi bundles. In fact, there was a lot of talk about OSGi at JavaOne, as noted by No Fluff speaker Vladimir Vivien, among others.

So, granted, it's a big deal. But still, what the heck is it?

Joseph Ottinger, editor of TheServerSide, has posted the first two installments of a series on OSGi. He says the idea is that he, "as a non-OSGi advocate, would like to take some time to try to explain OSGi to the people who don't know about it." And then he tries to get the definition out in under twenty four seconds:

The twenty-four second explanation: OSGi is a framework for Java in which units of resources called bundles can be installed. Bundles can export services or run processes, and have their dependencies managed, such that a bundle can be expected to have its requirements managed by the container. Each bundle can also have its own internal classpath, so that it can serve as an independent unit, should that be desireable. All of this is standardized such that any valid OSGi bundle can theoretically be installed in any valid OSGi container.

Only problem here is that not only is that longer than 24 seconds, it also doesn't explain why you'd want or need a module system. For the complete story, start with his first article,
OSGi for Beginners, which introduces the concepts of OSGI and shows how to build OSGi bundles, register services, build simple dependencies on other bundles, and look up services from other OSGi bundles. A second article introduces The Whiteboard Pattern for OSGi, advocated by some as a more efficient way to use OSGi, with an eye to its strengths and weaknesses.

And, apropos of the OSGi buzz, the latest Poll asks "What's your interest level in OSGi?" Cast your vote on the front page, then visit the results page for current tallies and discussion.

Also in Java Today,
the latest in the SDN's series of Enterprise Tech Tips is Ron Monzillo's Adding Authentication Mechanisms to the GlassFish Servlet Container. "This tip will show you how to implement and configure new authentication mechanisms in the GlassFish v2 servlet container. GlassFish v2 includes implementations of a number of HTTP layer authentication mechanisms such as Basic, Form, and Digest authentication. You can use the techniques described in this tip to add alternative implementations of the included mechanisms or to add implementations of new mechanisms such as HTTP Negotiate/SPNEGO, OpenID, or CAS."

In another JavaOne interview podcast, Barton George is Talkin' with Charlie and Tom, the JRuby Guys. Topics include the history of Ruby, Rails, and JRuby, licensing choices, JRuby's integration with GlassFish and NetBeans, the DaVinci machine project, jMaki, and whether we might see a JPerl.

The latest JavaOne Community Corner Podcast is
j1-2k8-mtT05: Project Wonderland: Community-built Virtual Worlds.
In this session, Nigel Simpson and Nicole Yankelovich show a number of different virtual worlds built by members of the Project Wonderland open source community members. Each highlights different aspects of the Wonderland platform and the wide range of possibilities open to developers.

In today's Weblogs, Giovani Salvador wonders about job candidates' understanding of architecture and the "big picture", in the blog
Java Architectural Knowledge for Job Interviews. Are we prepared?
"In lots of job interviews I have participated as interviewer for Java positions it is clear the lack of architectural knowledge some developers have. Here I post a typical dialog between one developer and I and some considerations about it."

Check out
Embeddable GlassFish in Action - Servlet in a Maven project. Arun Gupta writes,
"Kohsuke announced the embedability of GlassFish v3 - this is really cool! Now you can run GlassFish inside an existing JVM, without the need to start it externally."

Finally, with some hackery to wrap the week, Rémi Forax shows off
Javac + invokedynamic.
"To celebrate the public availability of JSR2 EDR, i have patched javac (yes again) to be able to generate method call using invokedynamic."

In today's Forums,
ocean wonders
How to automate webstart deployment.
"How are people automating their webstart deployment? I'm returning to the webstart fold and I'm a bit saddened to see that it's still difficult to automate a webstart deployment. So I'm curious if there are any solutions out there that I simply don't know about. Any magical ant tasks that offer push button automation for webstart? I've searched google and come across a few but they all seem to be woefully out of date. So what are people using to automate their webstart deployment?"

kcavanaugh has a detailed explanation for a thorny CORBA problem in
Re: Possible to include HTTP header information as part of RMI-IIOP?
"Yes, it is possible to do exactly what you want to do by adding a CORBA ServiceContext to the GIOP request and response headers. The programmatic API for this is called Portable Interceptors. Using it is a bit complicated, but here are a few references (also easily found on Google)..."

Finally, Shai Almog points out the latest forum / mailing-list mirror, in
Re: Mailing list cross posting to newly created LWUIT forum.
"Thanks again Roger. We now have a forum infrastructure similar to the one used by other projects it can be accessed here: Notice that what Roger fixed is that posting there should be mirrored here. If there are any problems please let me or Roger know about it."

Current and upcoming Java

Registered users can submit event listings for the href=""> Events Page using our href="">events submission form.
All submissions go through an editorial review before being posted to the

Archives and Subscriptions: This blog is delivered weekdays as
the Java
Today RSS feed
. Also, once this page is no longer featured as the
front page of it will be
archived along with other past issues in the href=""> Archive.

The increasing prominence of OSGi


It's not perfect, but the following blog entry attempts to explain what JSR 277 (and the already existing OSGi) try to solve:

Modularity in the Java Platform

Meaning, that the larger whole isn't predefined. Rather it can be used in different contexts. (For example, NetBeans could do like Eclipse and switch to OSGi. Eclipse didn't always use OSGi, if I understand correctly.)

OSGi: Java classpath management is a pain. OSGi lets you statically or dynamically add, update, and remove libraries in an app without worrying about conflicts so much. It's like the upcoming Java Module (jam) system, but it's available yesterday and covers more use cases.

Modules are to classes what classes are to methods. A way of encapsulating a functional area of code such that it can be independently loaded, tested, re-used, and re-implemented. The slides for the "Converting (Large) Applications to OSGi" JavaOne2008 talk are up on BJ Hargrove's blog: The talk focuses more on the how than the why, but I found some good background info there.

Chris, I have attempted to answer your question "why you'd want or need a module system" on my blog:

Sounds all like NetBeans Modules to me. Is there something like a comparison Chart or a "OSGi explained to NetBeans Module developers" out there? Will there be anything similar to layer files?

vorgi: Good idea. I don't know NetBeans Modules, but I imagine that they have a lot in common. Also similar to web apps or old-timey applets (before the newfangled process-per-applet model starts to kick in). The point of OSGi (so far as I understand it) is to be focused specifically on this task rather than being part of an expected larger whole.