Faster developing in OSGi with '-console' and 'update'

Just a little hint for those who work with OSGi on a daily basis.
Starting and stopping an OSGi-framework takes time, even for small projects. Working on a bundle that requires a lot of playing around can become quite painful when you have to wait those precious 5 seconds or more until the system is restarted.
Thankfully the OSGi-spec already provides an update facility.
Each bundle can be told to update itself from the location it was loaded from.
That last part is the important part and made my life a lot easier.
Most, if not all, OSGi developers already use the console to get handy commands like 'ss' or 'services'. Another nice command is 'update <bundleid>'.
The cool thing about 'update' is that even bundles you included from your workspace can be used.
Just fire up the framework with the '-console' parameter and whenever you changed something in your workspace use update to get those changes into your running framework.

Embracing Groovy

Actually it's not that much about Groovy than it is about scripting.
After a yearlong battle I finally got my way and we added scripting capabilities to the Rifidi Emulator.
Scripting became an important issue as the scenarios we wanted to create grew more and more complicated.
Now that we also have to support RSSI (Received Signal Strength Indication) we need to be able to simulate tons of different reads with varying tag properties. Something that simply wasn't possible in TagStreamer.
So finally the management agreed that we had to include scripting support.
I already had quite clear picture of what I wanted to achieve and how the thing should look in the end.
So here is a quick outline how Groovy got hooked up to the emulator.

1. At first we had to get rid of the PlugIn-Registry from Eclipse. We were using extension points to register the different reader implementations but decided to be OSGi compliant a while back. We ripped out the registry and replaced it with OSGi-Services and Spring.
2. The nice guys at Groovy were kind enough to already ship an OSGi-enabled jar. So I just downloaded the current binary distribution and put groovy-all.jar into our target platform.
3. We took our RMI interface that we had added to allow TagStreamer to use Emulator instances remotely and refactored it a little.
   We basically made it more scriptable by exposing a couple of helper functions for creating tags and managing readers.
4. Integrating groovy with the new interface was the easiest part:
   Using the executor pattern we start a new Groovy Shell for each script. Each script gets a reference to the reader management service injected and can now create/destroy/start/stop... readers and tags.
5. Now to the part that I like the most:
   We have been using the Equinox-OSGi-console for quite some time now and we love how extensible this little bugger is. We added a couple of new shell commands to manage the scripts.

That's it. 5 days of work and we got full scripting into the emulator. It's not perfect but it will be improved while we use it.
Things we need to work on:

• Integrate with Eclipse (We want to make use of the great tooling Groovy has there)
• Integrate with Edge Server UI.
  
• Start distributing scenarios.

But for now I am quite happy with what we got :)

Exporting an OSGi application from Eclipse

Sometimes working with Eclipse feels like arcane science.
Creating a pure OSGi (Equinox) application is as easy as it can get.
Running and tuning are dead simple. Manipulating the runlevels works like a charm (needed to get load time weaving integrated).
But then try exporting it.
After a little painful research and some nice hints from the newgroup I got the following process:

1. Create a product from your launch config.
2. Open the product and go the configuration-tab. You will only see the bundles that were designated to be auto-started at a certain level. Add all other bundles and set them to auto-start at level 4. The funny thing here is that these are the default settings for every OSGi-Framework application, but in a product the default is to not auto start anything.
3. Now make sure that all fields on the overview-tab are blank (Application has always a preselection, at least on my install)
4.  If you haven't done so before add org.eclipse.simpleconfigurator to be started in level 1.
5. Start the Export Wizard.
   
6. Make sure that "Synchronize before exporting" is UNSELECTED, otherwise the export will fail.
7. Export.
8. If you don't have the delta in your target platform you will now have to copy the native fragments into the export.

There you go.

Spring, @Comparable, OSGi, Eclipse RCP in Eclipse Magazin

I wanted to post how I got Spring to use AspectJ for DI in Eclipse RCP applications. The post won't happen as I wrote an article about it for the German Eclipse Magazin. As soon as the article is out you will find a link to it in here.

OSGi + Spring = ?

It took me a while to get back to my beloved Spring.
Before I start raving about this great framework some intro why I am doing this.
Dependency Injection is one of my most beloved patterns. It removes a lot of boilerplate code from your software if correctly applied.
When we started the Designer project we were looking into spring-osgi but decided to wait for the first final release to incorporate it.
Lookign back I don't know if that was the best way to go. We had to implement our own DI-Service in OSGi. So far it has worked pretty good but with a growing project you want get rif od as many headaches as possible.
One headache is that now almost all aspects of Rifidi are using our custom DI-Service and that means we have to deal with new features (unbelievable, some people really want software to evolve).
It would be great to get replace it with Spring-DM (the Spring OSGi project).
So today is the great day:
I will try to get services injected into an eclipse view.

Things accomplished this morning:

1. Target platform is up and running (will be up in Rifidi subversion as soon as I am done fighting with it)
2. Services get deployed to OSGi
3. Dependencies get injected (right now using xml config files)

Next steps:

1. Get AOP up and running.
2. Inject services using annotations
3. Get a view injected with a service
   

JAXB vs OSGI

A side note to those poor souls who have to get JAXB running with OSGI:
It works, but it is ugly.
A little story about the problem:
We have a ton of classes implementing different interfaces.
After putting a lot of work into refactoring the first release of designer I had created a ton of new interfaces.
We came to the point where we wanted to save all those nice classes with all the nice interfaces they implement to an XML file.
Since JDK 1.6 update 4 JAXB 2 is included in the JDK and we figured it might be good to give it another shot.
To make it short: as soon as one of our properties had an interface as its type the saving failed.
We followed the instructions on this site but JAXB kept telling us that it is unable to handle interfaces.
After some fiddling in a sandbox and reading through some osgi stuff I finally found out what to do:
Add the following JVM parameters and you are good:

-Dosgi.compatibility.bootdelegation=true -Dorg.osgi.framework.bootdelegation=*

It's a little brute force to do it this way and you will have a small performance impact on your app but at least it works.