An OSGi update

This is a short follow-up to Petr Jůza’s article OSGi. To use it or not? on OSGi and J2EE. I had a very interesting conversation about OSGi with Jürgen Höller of SpringSource at a conference here in Prague last week. We discussed deployment options. In his view, the best environments for an OSGi application are the following.

• A standalone OSGi container
• A servlet container such as Tomcat or Jetty, where it’s easy to bridge the web application’s dedicated class loader

Full-fledged application servers are a poor fit, especially if you want to use enterprise features such as EJB. I discussed the possible future of OSGi and J2EE with him and others. My impression is that people are skeptical OSGi will be supported as a deployment model for enterprise applications. That certainly goes for J2EE 6, which will concentrate primarily on APIs and SPIs. It’s hardly surprising. This would be a huge change to the existing J2EE model.

Here’s my own take. If OSGi does make it into J2EE, I think it’ll slip in through the side door. GlassFish announced that it will support deploying OSGi bundles. Other servers may follow in time. It seems better to wait and see what works in practice than to invent a model from scratch.

I like the idea of OSGi and hope it catches on. For enterprise applications, though, I still see problems on both the development and deployment sides. In an enterprise setting, strong tooling for development and administration is essential.

That’s worth considering if your team isn’t made up entirely of star developers or if you don’t administer the whole application yourselves. Right now much of it feels like it’s still in its infancy, and you have to cobble everything together by hand. That won’t go down well with your managers or your customers.