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!

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

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! :)

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! :)

flex, cocomo and the diablo iii fansite kit

It has been a while and lots of things have been happening. I'm still working away on the first implementation of DataEye which should go live any day now.

I have also managed to create a set of bundles which allow Flex Remoting via AMF3 in a pure OSGi environment (i.e. no BlazeDS). However, they are not a replacement for BlazeDS, they are just something different and provide no "data services" to speak of, other than allowing developers to register their OSGi services and then access them from their Flex applications. A sample application will be provided. Once I get the thumbs up from the lawyers and my boss I intend to release them, so watch this space.

Since I couldn't sleep this evening (I have only been in my new house less then a month and things are still a little strange) I decided to see how Diablo III was progressing. I am really looking forward to this game. I noticed they had a Fansite Kit available for download, so I took a look. I didn't intend to build a fansite, I'm not a web designer, but I have been looking for an opportunity to play with Adobe's Cocomo SDK and see what it is about.

The result is the linked page. http://diabloiii.brindy.org.uk/

Cocomo is really simple and seems to be very comprehensive in the things it lets you do. My application is really just a simple Flex application with no server back end. All the server stuff is provided by the "connectnow" service at acrobat.com (http://connectnow.acrobat.com/).

The only things I don't like about it are the examples aren't really good examples of best practice approaches and even goes against some of the things Adobe says not to do (lots of containers within containers) and the other thing is to do with containers directly. Adobe seem to love them and seem to love inheritance as an approach to specialism. I prefer composition over inheritance, and while there's a bit of that in there too, what you end up with is a complicated mess of container hierarchy, models and so on.

But really, if you're used to Flex, this won't be a shock, so don't let it put you off!

I am thinking that Cocomo combined with the the Facebook API for Flex that I found here might be very interesting...
http://code.google.com/p/facebook-actionscript-api/

OSGi Primer

I find myself explaining OSGi from time to time, so decided to try and write a very brief primer to describe the essentials of OSGi which I can simply link to in the future. This short entry is aimed at people who no nothing or very little about OSGi and should be just enough to make the penny drop.

Here goes!

Firstly, I'm going presume that the reader is familiar with Eclipse IDE. If so, then the reader has already been using OSGi and probably doesn't even realise it.

The Eclipse IDE is constructed from Plugins. Plugins are effectively OSGi bundles with a bit extra (usually a plugin.xml, sometimes a little more).

Eclipse is built on top of Equinox which is an implementation of the OSGi specification and then goes on to extend it with the Plugin Registry.

At its core an OSGi bundle is a standard Java JAR file with some extra information in the MANIFEST.MF which describes the bundle to the OSGi platform it is deployed to. The manifest describes things like the bundle's name, version, what packages and/or other bundles it depends on, what packages it exposes, and probably a fair chunk of other stuff I haven't mentioned.

OSGi is a service oriented architecture. This is quite an important point to me as most people hear or read SOA and automatically assume Web Services. Well Web Services are just one type of SOA. The specification of OSGi is inherently, and by design, service oriented.

Like I said, bundles can declare what packages they expose, but more importantly they declare and/or register services.

A service is essentially a Java interface and can be implemented by one or more bundles. A bundle that needs to use a particular service looks it up (or "tracks" when services are registered/unregistered) and then decides which service to use either by taking the first one it finds, or by homing in on a service that meets a specific need by specifying some service properties.

The most important thing is that services are dynamic. They can come and go and this is a part of the specification and something that any one who writes bundles has to accept and deal with.

As a result, OSGi has a tightly defined classloader mechanism which manages version control. You can have two bundles installed on your OSGi platform that expose the different versions of the same package, then other bundles can be explicit about which package version they depend on or not.

The OSGi specification consists of a core specification and a service compendium. The core specification is enough to write modular Java applications and the service compendium details a selection of services that OSGi implementations will usually implement a common set of, if not all of. These include things like Logging, Declarative Services (services can be declared using XML), HTTP service (you can expose web resources from a compliant container, some even support JSPs!) and others. See this page for more information:
http://www.osgi.org/Specifications/HomePage

Finally, what I haven't mentioned is that OSGi has been around for nearly a decade. It was originally intended for use as a dynamic platform for embedded devices but IMHO is really starting to make its mark through use on the desktop and (enterprise) server areas, especially in the last couple of years.

When you get in to it, the power of OSGi is mind boggling. Yet OSGi is simple and logical, while remaining comprehensive. OSGi is the modularity that Java is missing.

I hope my brief description of OSGi does it justice. I deliberately wanted to keep it short and sweet and whet some appetites.

how to sell RIA

I was just discussing with my colleague Vince the merits of discussing technology as part of a sales pitch. For instance, if you're selling your services as an RIA consultancy you don't want to be describing Ajax or even GWT. It's just confusing and irrelevant. "Can you do the job or not and will your platform fit in to our infrastructure?"

Talking abot technology is just too low level for that first business pre-sales pitch... but as Vince pointed out, and I have to agree, this is not the case with Flex.

Somehow Flex has a "coolness" about it that can sell itself. So while pitching yourself as RIA specialists, if you used Flex you would most likely mention it and mention Adobe and the majority of customers would probably feel pretty good about your pitch as a result.

This is pretty funny, because the Adobe marketing machine is pretty agressive, but apart from a few minor features I am yet to see something done in Flex that couldn't be done in GWT (or some other Ajax/RIA framework).

This raises question, "why am I using Flex?". The one thing it does have, which the other frameworks don't seem to, is modularity. I've mentioned this before, it gives Flex developers the ability to put big lumps of code in to different SWF files which are loaded as needed. We take advantage of that (and OSGi on the server) in Solstice to create our modular RIA platform.

Can't do that with GWT, it's an all or nothing approach. Want to add a new feature? Recompile you're whole application.

I just wish Adobe would see the value of OSGi and get on board. BlazeDS would be an awesome OSGi bundle.