OSGi First Impressions

Lots of new technologies since starting this job in July. The most interesting ones turn the JVM into something more like a micro-kernel operating system. Since Java 1.5 MBeans ship as part of Java runtime. Since Java 1.6 MXBeans ship as part of Java runtime.
This application leverages that in a big way. Using Apache libraries that implement the OSGi specification, the application dynamically installs, starts, stops and uninstall features. Other Apache libraries provide a command line style interface to interact with the services and features.

The advantages of this approach are obvious. Uncaught or unrecoverable exceptions in one runtime component do not take down the entire JVM and failed services are restarted quickly and quietly. The approach also provides a more declarative way to build application. Apache Aries compiles blueprint XML files to provide dependency injection. And OSGi supports more a more flexible dependency framework than base Java's class path and class loader.

Of course, this flexibility comes at a cost. Debugging is more difficult than debugging POJOs. There is a big overhead and lots of configuration dependencies to bring up the containarized environment. It slow and delicate. Also, automated test become very flakey, very quickly. For example:

• For years there was a single provider of the SecurityConfiguration service. Recently a second implementation was created to support external credential providers. Everything ran fine for a week, but the CI builds started failing occasionally. At the time, no one had any idea what was going wrong or why the failure were intermittent. Turn out, the tests were simply taking the whichever SecurityConfiguration provider registered itself first. In a more synchronous environment where it is easy to step through the code, this would have been obvious. But because of the mountain of frameworks and the loose coupling, finding the issue was a tough.

• I was blocked for a day trying to register a new MBean. Eventually, a long-time project member spotted the problem. The blueprint file that would be read and create the bean was in a directory named OSGI-INF.blueprint. All of the blueprint files were in directories with that name. Except, there weren't. The IDE was concatenating the names of resource directories the same way it concatenated the name of Java package directories. The blueprint builder would descend into the proper resource directory, but it was looking for a directory named "OSGI-INF" with a subdir "blueprint", not "OSGI-INF.blueprint". Not finding such a directory, it moved on without any logging or notification.