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.

Living without friends sucks

And again I stumble over a scenario where it would be so absolutely helpful to have C++-like friends in Java.
Again I need to jump through hoops to get the desired behavior.
I am working on an integration of our SAL (Sensor Abstraction Layer) with Esper.
But the messages from SAL can go to other receivers like JMS, too.
The problem comes form the fact that the messages coming from the SAL have to be readonly to not mess Esper up.
As I like my code easy readable I prefer setters over big constructors. But in this scenario setters would be very problematic as they would allow the manipulation of data at any point in the future. Something that must not happen from the moment on the message went into Esper.
So public setters are a no go. Protected setters don't work as they are only accessible from the same package. So I end up having to write a big constructor, collect all the data from the different sources and then create the object.
Exceptions might be another way of solving the problem. But all the boilerplate code ...
Wouldn't it be nice to declare it protected and define a list of friends who can access it?
Then I would be able to create the object, pass it to the friends who are allowed to access the setters and then put the object into Esper without having to worry that somebody messes up my messages.
So sad.
Note:
I put together a little idea using CGLib and a set of different interfaces to built a proxy based solution. As soon as I get some time I will post it here.

Apache Commons Logging. IT'S A TRAP!

Apache Commons Logging (ACL) is a nice idea when you first stumble upon it:
Develop your app using commons logging, use whatever logging backend you want to use and let the guy deploying decide what he wants to use for logging.
So far so good. I liked the idea. We are using commons logging all over the place.
Now reality hits.
Two weeks ago we started a new project. This time we wanted to do everything right and wanted to get all logging centralized. Piece of cake when everybody is using it ... which is simply not the case.
Having tons of open source libraries in there we finally had to realize that not all coders bought into the idea of ACL. Which is perfectly understandable as it adds another layer to your logging, another jar to the classpath and it takes away the logging interface you came to love over the years.
People use ACL, log4J and *shudders* Java-Logging. How do you handle that?
A while ago I read a post about a new logging wrapper. The post was incredibly misleading and bad researched so I almost dismissed slf4j. Thankfully I looked again.
slf4j was actually what we needed.
So what does it do?
It's quite simple:
It's a log syndication tool. It just collects logging output from all kinds of different sources and redirects it to your logge rof choice.
Awesome, finally someone got it right.
Using it in OSGi makes my life a lot easier. Using OSGi I could sneak in the replacements for org.apache.commons into all libraries and could also catch logging output from all other sources.
Give it a shot and please, remove ACL from your project, it's a waste of time and space.