Saturday, 27 December 2008

Logging in OSGi

Remember that OSGi is a dynamic environment. Also remember that there is a specification for a logging service, 'LogService', which is my preferred approach to logging inside OSGi. Considering that OSGi is a dynamic environment this of course means that the log service may not be available.

Within Solstice we use a static implementation of the LogService interface which we can access through a static final variable and is made available in the core bundle which pretty much all other bundles import a package from. This implementation simply logs to System.out and is cunningly called SystemOutLogService. The reason it exists is just in case a LogService has not been registered with the container. To be honest, this seems pretty redundant since Solstice is an OSGi implementation (based on Equinox) and we're fully in control of what is in the distribution. Also, this doesn't seem very elegant.

In our recent release of AMF3 for OSGi I have assumed (and it is in the documentation) that a LogService will be available. At least one of the bundles tracks LogService implementations and then injects them were needed. However, OSGi is dynamic, so I can't assume that everyone will want to have a LogService implementation. So what is the solution?

One idea is to re-implement the SystemOutLogService, but I don't want there to be a core bundle that each of the bundles depends on (either explicitly, or implicitly through packages). Further more, I might as well just register my own implementation of LogService if I am going to do that - but then how do we make sure that other LogServices get priority? Well, this is possible by setting the OSGi service priority to a low number and then making sure we use the one with the highest priority. However, this is moot since I don't want to provide this functionality at all, or put any logic to handle the priority of LogService implementations in to my trackers.

So, we fall back to System.err by doing a null check on the injected LogService implementation. I'm not really happy with this either, but it is the default thing to do for Java as it is the only thing that can really be depended on to exist.

My feeling therefore, is that logging should be available at a more fundamental level, i.e. in the core specification. A logging API has been available in Java since 1.4, not that I have ever used it as I have generally used Log4j outside of OSGi. I don't think that LogService should be deprecated, but rather than having to look up a log service, you should be able to call a log method on the BundleContext which does something 'default' or delegates to any registered LogService implementations by priority. I guess that implies that a default LogService could be accessed from BundleContext instead, which further implies that LogService should become part of the core specification ... any thoughts on that out there?

By the way, we've created a Jira for Solstice, AMF3 for OSGi and any other open source projects, please feel free to create issues:
http://jira.arumsystems.co.uk:8080/

And finally ... anyone who's already downloaded the AMF3 for OSGi distribution already may have noticed that the source for the HTTP bundle was a copy of the Flex Remoting bundle. That's been fixed, please re-download it!

Tuesday, 16 December 2008

AMF3 for OSGi, 1.0.0, released

Today, Arum Systems Ltd released AMF3 for OSGi, 1.0.0.

AMF3 for OSGi is a collection of bundles that adds AMF3 serialisation, AMF3 over HTTP and Flex Remoting of OSGi services capabilities to your OSGi applications.

Best of all, this is released with a LGPL license.

For the full details and downloads visit this page:
http://www.arum.co.uk/amf3osgi.php

Sunday, 7 December 2008

This blog has moved!

You may have noticed that this blog has moved to a new URL. Please update your bookmarks!

Coming soon:
- AMF3 for OSGi release
- OSGi and db4o tutorial
- a vacation! :)

Monday, 1 December 2008

Seasons Greetings!

Here's a little something I knocked up using images from Flickr (mostly subject to the this license) and a couple of useful APIs, namely FlexBook and Flint (the Flex particle system).



Thanks to Matt at Arum for finishing it off by adding all the images - even I don't know what's in there! :)