server side osgi, a myth?

Two years ago, I started using OSGI, the popular Java dependency injecting component standard, for an internal project. Fast forward to now and I have a nice set of bundles that depend on, amongst other the OSGI HTTP service.

All along, I’ve been reading how great OSGI is and how flexible it is and how it is the future of server side Java. I was ready to believe it. But to cut to the meat of this blog post: server side OSGI is vaporware. It doesn’t exist. None of the vendors actually support it. Support it as in production quality, well documented, widely used product available right now. I’ve looked at Felix, Tomcat, Equinox,  Jetty, Glassfish, JBoss, etc. and came up with nothing but a few obscure, unsupported, undocumented components. The default HTTP service implementation is not my idea of scalable & production quality. And the connections of existing production quality OSGI containers to existing production quality application servers is sketchy at best.

Frankly, I’m very surprised at this.I know lots of people that claim use OSGI serverside and there are are lots of announcements of vendor X endorsing OSGI bla bla bla fully modularized bla bla bla dependency injection  bla bla bla. That’s great but after two years of OSGI hacking I was hoping for something a little more substantial than what I have found so far:

The best option I came up with is the HTTP servlet bridge from equinox. The documentation for this is either hopelessly out of date or this is a case of abandonware. Basically all the page says is download this bridge.war and good luck. Problem #1 this bridge.war is from 1997 .. eh 2007 :-). Problem #2, I’d like to use a bit newer version of Equinox. Does this work at all? Are people still working on this? Problem #3, this page hasn’t changed substantially since I started using OSGI. Is anyone still working on this or is this a dead project? Are there any users?

Option #2 is to use Apache Felix which apparently can embed Jetty. That’s great but I’m a tomcat guy and am more interested in using tomcat as the outer container than Jetty. Neither the jetty nor the tomcat option is documented properly. I’m not even sure the tomcat option is possible/advisable. Some people hint at this being possible. A particular concern for me is that I need to cluster the damn thing, potentially on a large scale. Is this possible at all? I’m pretty sure people have done this but in terms of production quality code and documentation they have not left much of a trail. The Felix people don’t seem to much documentation in general. There’s of course the gratuitous OSGI tutorial and some hints of how you could use it but that’s it.

This situation is not something I can sell here at Nokia. I need something more substantial, preferably Tomcat or JBoss based that is 1) scalable in a cluster 2) production quality 3) well documented. I’m now pretty far convinced that what I’m looking for doesn’t exist. If I don’t find something soon, I’m going to just have to rip out all the OSGI stuff and switch to a proper dependency injecting container. Spring 3.0 is looking pretty neat for example but a bit heavyweight in my opinion.

Anyway, comments are open and please point out how wrong I am and what information I overlooked :-). My main gripe here is that I just have very little to base a decision on. Sketchy documentation, bits and pieces on blogs and mailinglists but nothing solid. Either OSGI is a genuine server side option or it is just an urban legend (some people have heard of other people that have done this). Everything I’ve seen so far hints at the latter.

I know Jboss 4, Glassfish 3, and Spring Application server are all going to be OSGI based of course. These are far from vaporware but also not exactly production ready. Additionally, being OSGI based is one thing, being able to deploy servlets from OSGI bundles is another thing. Most things I’ve read on this suggests that these servers are not really designed to allow application developers to interact with the OSGI container directly (i.e. deploying bundles, using http service instead of WAR files, etc.).

5 Replies to “server side osgi, a myth?”

  1. I work in GlassFish and am mostly responsible for implementation of OSGi aspects of GlassFish. I would be very interested to know what your requirements are. Feel free to drop me an email either at sahoo (at) sun (dot) com or users (at) glassfish (dot) dev (dot) java (dot) net.

  2. The servletbridge is most definitely not abandonware and is being used as the foundation of several commercial products both at IBM and elsewhere. The documentation on the web site… well that’s a problem; ti is admittedly hopelessly out of date and the posted WAR file is only meant as a quickstart. With that said that state of the online docs does not reflect the real work going on in that both the servletbridge and jetty based http service are fully supported, maintained and improved every release. One excellent resource for the server-side equinox efforts is the equinox newsgroup. Another place to look is at the posted slides from Eclipsecon. Finally, there’s also a book on Equinox in the works that will provide some coverage of the servletbridge.

  3. Hi Simon, good to hear that the project is still alive. The lack of documentation and support is an issue though. I don’t really have time to piece together from news groups and other sources what to do here. That’s fine for early adopters of course but I need a bit more solid stuff to be able to sell this at work. Right now this just looks a bit too immature and early to start using commercially.

  4. I’ve moved on. Haven’t come near anything osgi in 18 months. I don’t believe it solves a problem I actually have. There appears to be no significant progress regarding deploying web applications as OSGI bundles, so I guess most of the industry is equally unexcited about the prospect of doing so.

    I am using spring now and it fulfills most of my needs, though I still think it is a bit bloated. In general I am rather bored with how bloated enterprise Java has become relative to things like python django, ruby, scala, erlang, etc.

Leave a Reply