Is the Ω problem really a problem

At the OSGi Community event last week (and on a blog post[1]) Alex Blewitt outlines "the Ω problem". The basic thesis of this problem is that Enterprise OSGi adoption is being hindered because all the relevant projects have unintelligible names based on "greek letters and astrological". He quotes Apache Aries, Eclipse Libra, and Apache [Felix] Gogo as examples. As a committer on Apache Aries and as someone involved in Enterprise OSGi I take some small exception to being singled out like this.

What's in a name? That which we call a rose
By any other name would smell as sweet.

I spend far too much of my life arguing over names. The trouble with names is the barrier of entry to the debate is so low everyone can engage and voice an opinion. So are names important? The answer is I think yes and no. In a (slightly tetchy) twitter exchange (which was all my fault) I asked Alex how he would like to fix the problem, how to apply the fix to the Apache Aries JNDI module. His suggestion was:

• Apache Naming for OSGi
• Apache JNDI for OSGi [2]

There are a few potential issues with this proposal. These complicate the matter rather than prevent the names being used, but they need to be considered:

1. OSGi is a registered trademark of the OSGi Alliance. While it is valid to use OSGi in product or project names in some cases you need a lawyer to know what they are. As a result putting OSGi in a name is somewhat tricky. (I hate to bring lawyers into this, but it is worth mentioning)
2. The Apache Aries JNDI module does not provide a Naming Service which could be implied by the former name. I've had many conversations with people who assume Apache Aries JNDI provides a name service. When I point out that the response is typically "oh yes, that makes sense".
3. It doesn't really fit with the Apache way of doing things. The ASF is a federation of projects this means that you can have multiple projects doing the exact same thing. While this might sound odd there are several potentially competing projects; Apache CXF and Apache Axis2 for example are both Web services stacks. This means it is completely valid to have multiple implementations of the OSGi JNDI specification. This might seem odd, but it is possible that the Apache Felix project and Apache Aries might both choose to implement the same specification. This then becomes a problem using names like those suggested because there are two things in Apache that should have the same name. I can't speak for Eclipse, but it could easily be the same thing there.

All this really highlights is the problems associated with naming. The most likely best improvement based on Alex's suggestion is "Apache Aries JNDI for OSGi" which isn't a huge improvement. This leads me onto a second observation.

In Alex's blog he identifies Spring Data, Spring Web services, Apache Commons Lang as good names, and Apache Aries as bad, but this isn't comparing like with like. If we deconstruct the good names they follow this pattern:

   <brand> <function>

The "brand" in the names is "Spring" and "Apache Commons"; the function is "Data", "Web services", "Lang". If we look at two items from the bad list (and I'm choosing the two I have some familiarity with) the quoted names are the brand and do not denote the function. The two I'll quote from are Apache Aries and Eclipse Gemini. Both these projects have the following:

• Apache Aries Blueprint
• Apache Aries JNDI
• Eclipse Gemini Blueprint
• Eclipse Gemini Naming

The project or brand is Apache Aries, the function is Blueprint and JNDI.

So back to the original title of my blog post. "Is the Ω problem really a problem". For me the answer is no. Naming is hard, and I am sure we haven't got it right, but the names of things aren't the problem. I think there are some real problems here that need to be addressed, but we need to focus on those rather than deciding that naming a project Apache Aries, or Eclipse Gemini is weird (or by implication of not being good, bad).

Before I sign off I think some of the problems we have to address for adoption of Enterprise OSGi:

• Explain to people the benefits
• Better integration into more Application Servers.
  In fact since WebSphere Application Server,  Apache Geronimo, Glassfish and JBoss OSGi are all doing this perhaps it is making people aware of what is out there.
• Better support for the a la carte model familiar to many experience OSGi people.
  I think there is a debate to be had around this. In the enterprise world a la carte is more complex than in previous OSGi arenas. You can certainly have an a la carte model for an application that uses Servlets, JPA, transactions and Blueprint (we have a sample in apache aries that builds its own runtime like this) in reality once you have done this you have pretty much built your own application server at which point you should be looking to reuse what others have done.

Alasdair

[1]http://alblue.bandlem.com/2011/09/omega-problem.html
[2]https://twitter.com/#!/alblue/status/118763089289158656

P.S. I'm too anal not to point out the following minor errors in the list of names in Alex's blog:

• Apache RegExp is really called Apache Jakarta RegExp (this is retired and in the Apache Attic)
• Apache Gogo is really Apache Felix Gogo
• Apache Sigil is really Apache Felix Sigil

Blueprint 101 - destruction

I have recently come across a couple of cases where a blueprint bean destroy method takes a long time to run. This has resulted in undesired behaviour. In both cases the destroy method took over 5 minutes to run and then failed with a runtime exception.

So what was going on? In this case the destroy method ended up invoking a service that had been injected from a element. Lets look at a quick example. 

In this diagram bean A in the left hand bundle uses bean B in the right hand bundle via a service relationship. Bean A's destroy method calls out to bean B. In blueprint service references are damped, this means that if the target service has gone it blocks the call for a timeout period (the default is 5 minutes) until a replacement can be found. If no replacement is found an unchecked exception is thrown.

The most common reason for the destroy method of bean A being invoked is that the left hand bundle has been stopped. If only the left hand bundle is stopped then this will work just fine, but both are stopped then the right hand bundle must be stopped before the left hand bundle. The problem is there is no way to enforce this shutdown order.

So having outlined the problem the question that will come up is "how to solve it?". The answer is to not call a service in a destroy method. This is quite simple, but doesn't help if you really need to call that service. Instead of placing this call in the destroy method though you can make use of another feature in blueprint called a reference listener. A reference listener gets called when a matching service is initially bound to a reference, or when a service is unbound (if a service is replaced the unbind method is not called, but the bind method will be called to indicate the service has been replaced). Moving the tidy up out of the destroy method and into a reference listener will ensure the call can succeed. The reference listener is called irrespective of the order of the left and right hand bundles being shutdown.

Using a reference listener is slightly more complicated, it involves a little more XML. Instead of defining:

<bean class="my.example.BeanA" destroy-method="destroy">
    <property name="service" ref="serviceRef"/>
</bean>
<reference id="serviceRef"
           interface="my.example.BeanBInterface"/>

you define the following:

<bean id="beanA" class="my.example.BeanA">
    <property name="service" ref="serviceRef"/>
<bean>
<reference id="serviceRef"
           interface="my.example.BeanBInterface">
    <reference-listener ref="beanA"
                        unbind-method="unbindBeanB"/>
</reference>

The signature of the unbind method should be public void unbindBeanB(my.example.BeanBInterface), it could also take a ServiceReference. Normally blueprint does not allow beans to have cycles, that is bean A depends on bean B which depends on Bean C, as is clearly shown in this case. However the blueprint specifically specifically requires blueprint container implementations to support this kind of cycle.

Making this change removes the ordering constraint between the two bundles and produces a more resilient system.

Alasdair

Updated 4th September 2011: Updated to correctly describe the behaviour of a reference listener when a service is switched.

Blueprint 101 - Brief introduction to Blueprint

I haven't said much in a long time, and once again I'm back promising to do better, and probably failing. However I am back and the main reason I'm back is I have been having a lot of questions recently about blueprint, and some problems people are hitting. Since my responses have mostly been in the privacy of my email program I though I should start sharing. Hence the Blueprint 101 title of this blog post. Rather than go over the basics below is a quick video I was "forced" into doing for the Enterprise OSGi channel on YouTube. I suggest you jump to 12 seconds in after I've gone from the screen and the slides appear.

Bio from a colleague

I hate writing bios. I pretty much avoid doing it at all costs. So one of my colleagues decided to help out by providing me out for the UK WebSphere User Group meeting for March.

Alasdair was sent to us from the future to encourage OSGi adoption & prevent the threat we know as Maven, that in 2025 would become SkyNet, a build system of such complexity that it became self aware, and realised that the main cause of build breaks were us, humans. In the last few years however, he has replaced his primary directive with one to bake cookies for mankind, in the hope that by supplying cookies, the threat can be averted without requiring the termination of Mankind. Alasdair holds many qualifications, including a Ma(Baker) in cookie making, and a 100m swimming certificate from junior school.

Somehow I think I'll pass.

Creating a Web Application Bundle Using Maven

Before explaining how to create a Web Application Bundle (WAB) it is worth reviewing what a WAB is. A WAB is basically a bundle that is structured like a WAR, but with OSGi classloading rules. It is a valid bundle, and also looks like a valid WAR (although it doesn't necessarily end in the .war extension, usually .jar is good enough).

A typical WAB might look like this:

META-INF/MANIFEST - containing all the normal OSGi info
WEB-INF/web.xml - the normal web deployment descriptor
WEB-INF/classes - class files and resources visible via the classloader
WEB-INF/lib/a.jar - a jar file
index.html
index.jsp
images/icon.png
style/style.css

The important thing about this is META-INF, WEB-INF (and OSGI-INF) are special in that content is not served up. As a result you want program metadata and classfiles to be in here, since they don't make up part of the web content. The web content goes into the root of the bundle.

Prior to the latest release of the maven-bundle-plugin you could either use the maven-war-plugin to generate a war with a manually created manifest, or you could create a maven-bundle-plugin at which point you would not end up with a valid WAB. You would get the classes, resources and static content mixed together in the root of the bundle. This did not produce good WABs.

With version 2.2.0 of the maven-bundle-plugin which was released this week by the Apache Felix project we have a new option. We can tell the plugin we want to create a WAB.

It is important to understand how the maven-bundle-plugin builds WABs to get this working. The maven-bundle-plugin under the covers makes use of the bnd tool. To get it to build you tell it you want to create a WAB and it relocates everything on the classpath so it is in WEB-INF/classes.

If you take the approach we did in the Apache Aries project for the 0.1 and 0.2 releases your project might be structured with java source in src/main/java and static content in src/main/resources. The upshot of this is if you just specify the following in the configuration for the maven-bundle-plugin:

<_wab/>

All the static content moves into WEB-INF, this is obviously a bad thing because it is no longer served by the web container.

So what we did for the 0.3 release was we moved the static content from src/main/resources and into the src/main/webapp directory. Then we added the following:

<_wab>src/main/webapp/</_wab>

This means everything in src/main/java is compiled and put in WEB-INF/classes. Everything in src/main/resources is put in WEB-INF/classes. This is pretty much what you would expect because these locations are used to put files that are loadable via the classloader. The content in src/main/webapp is then placed in the root. In fact in this scenario you put the web.xml in the src/main/webapp/WEB-INF directory, and if your WAB contains blueprint your blueprint would go in src/main/webapp/OSGI-INF/blueprint.

Alasdair

Creating Enterprise OSGi apps for Apache Aries

I was recently at JavaZone in Norway and JavaOne in San Francisco presenting on OSGi and Apache Aries. I gave a demo of how to create an enterprise OSGi application. The application I demoed the creation of was the blog sample from Apache Aries. That sample is built and created using maven, so I moved it into eclipse.

In the next few blog posts I will describe the steps involved in creating this sample using the tools and running them in eclipse.

Alasdair

Developing OSGi Applications with Apache Aries

Yesterday I blogged on how to get the free OSGi Applications tools from IBM Rational working on Eclipse 3.6 Classic. Having got the tools created the next step is to define a target platform. A target platform is the set of bundles you want to build and run your application with. Since Eclipse is a big OSGi application it already comes with a built in target platform for developing eclipse plugins. Since we are trying to create an enterprise OSGi application this isn't any good. We need a new one, but the tools don't come with one for free. In this post I will go through the steps involved in setting up a target platform for developing OSGi applications.

Before going on you'll need maven. You may have it already, but if not you can get it from the Apache Maven download page.

1. The first step is to get a "runtime" from somewhere. The quickest way to get something quickly and easily is to build the Apache Aries Blog sample assembly. This can be downloaded from subversion here. Download it into an empty directory.
2. In the empty directory run mvn. This will download all the bundles required to run the Apache Aries Blog sample. The bundles will be in the target subdirectory.
3. In eclipse you need to open the preferences pane and navigate to Plug-in Development > Target Platform. Click the Add button.
4. This opens a wizard with 4 radio buttons. You want to start with the first option titled Nothing.
   
   
   
5. The next page is the target platform configuration panels. The first step is to choose a name. I have gone with Apache Aries.
   
   
   
6. Right now the target platform has no bundles, so we need to add the directory of bundles we got from step 2. Click the Add button. A wizard will appear with 4 options, select the Directory option and click next. Then browse to the target directory generated in step 2.
   
7. We now have bundles we can build against, but this isn't going to help run any tests. Some of the Apache Aries bundles depend on javax.transaction. The problem is javax.transaction exists in the JVM, but only contains a few exceptions from the package which causes bundles wanting to use javax.transaction problems. to fix that we need to configure the target platform. This is fixed by going to the Arguments tab and adding the following as a vm argument:
   
   -Dorg.osgi.framework.system.packages.extra= javax.transaction;version=1.1.0,  javax.transaction.xa;version=1.1.0  -Xbootclasspath/p: ${target_home}/geronimo-jta_1.1_spec-1.1.1.jar

   This does two things. The first is it tells the OSGi framework to export the JTA packages at version 1.1, which is the version expected by Apache Aries, and the second thing it does is add the extra classes onto the JVM boot classpath.
   Note: I added some spaces into the example to ensure it wraps on the blog. The only space that should exist when copied into the dialog is the one before -Xbootclasspath.
   
   
   
8. Now you are done and can click the Finish button. The last thing to do is to make the new Target Platform the active platform. You can do this by checking the checkbox next to the platform you just created.
   
   
   
   Note: If you add or remove a bundle from the platform directory you will want to come back and hit the reload button to get Eclipse to notice.

Now you are ready to start developing your bundles, and when you want to test your application you can use the OSGi Framework Run configuration in eclipse. If you want to add more bundles to the runtime just drop them into the directory from step 2 and then reload the platform.

I'll blog another time about using the tooling to create a simple application.
Alasdair