Java EE specs in OSGi

For ServiceMix 4, I've been working on making sure the Java EE specifications can be used in OSGi. The first step was to release OSGi versions of the various specifications by just adding the needed manifest entries to make them usable in OSGi. This was done inside the Geronimo project (on which I am a committer). This means that since a few months, most of the Java EE specification jars are available as OSGi bundles (you can grab those from maven 2 public repositories.

However, this is not always sufficient. Some of these specifications (mostly JAXB, SAAJ, JAX-WS and Stax) do not work well in OSGi. The mean reason is that the implementation is discovered using different mechanisms by the API. The most commonly used one is to find a file on the classpath in the META-INF/services directory and find the main entry point class of the implementation. Unfortunately, to make this work in OSGi, the client bundle (the one using one of these APIs) has to have the required file in its classpath, which means the inability to use one provided by the runtime in which the bundle is deployed and that it can not be switched without changing and re-compiling the bundle. Another way would be to add a Require-Bundle OSGi manifest so that the classpath of the implementation becomes part of the client bundle, but this also ties the client bundle to the implementation used.

The solution came to me after a chat with Dan Kulp: an OSGi specific discovery mechanism can be easily plugged into these spec jars. It consists in two small classes shared amongst these spec jars: an OSGi bundle activator and another class not tied to the OSGi api that maintain a list of available implementations. The final step if to rewrite the factory of those jars to look inside this map before performing the usual lookup.

This means that in a non OSGi environment, the jar behaves as usual, but when deployed into an OSGi runtime such as ServiceMix Kernel, the spec bundle will be able to locate dynamically the implementation to use. Therefore, the client bundle using the spec jar is now free of any requirements.

JAAS in OSGi

I've working on implementing the security framework for ServiceMix 4. ServiceMix 3 used JAAS for the authentication part, and it also makes sense to use it in ServiceMix 4 for several reasons: reuse of existing login modules, integration with the JMX and the console security which are already based on JAAS.
However JAAS is not very OSGi friendly (well, most of the JEE specifications are not, and I'll talk about the others in another post), mostly because is makes some strong assumptions upon the thread context classloader, and this, mainly on the client code. This means the client that uses the JAAS api to authenticate has to have all the login modules available in its thread context classloader. This is usually not the case in OSGi.
So the solution is to use a proxy login module that will be available to all bundles (by using the boot framework delegation package). This proxy login module can use some OSGi properties on the login module configuration to determine the actual class to use and the bundle to load it from.
Using a simple XML schema for Spring, you can deploy a JAAS realm very easily:

<jaas:config id="realm" xmlns:jaas="http://servicemix.apache.org/jaas">
    <jaas:module className="org.apache.servicemix.kernel.jaas.config.SimpleLoginModule" flags="required">
        key=value
    </jaas:module>
</jaas:config>

This will register a service in OSGi that the OSGi specific Configuration for JAAS will discover and make it available for clients.

Find more informations on the ServiceMix Kernel JAAS doc.

ServiceMix 4 NMR on Equinox

I've done some experiments today to check that ServiceMix 4 NMR can be easily deployed on Equinox instead of Felix. Have a look at this wiki page.

Apache ServiceMix Kernel 1.0-m3

We've just released the third milestone of ServiceMix Kernel 1.0-m3. This small OSGi based container is really nice, if you haven't had a look at it yet, go and grab it.

It adds a bunch of cool new features. For example you can run:

osgi list | utils grep ServiceMix

or

log d | utils grep WARN

If you want to have a quick run at it, go and look at the quick start guide.