Monday, September 27, 2010

Two Karaf related Camel components

While thinking about a centralized logging system for Karaf and FUSE ESB, I had this idea that instead of using a built-in JMS appender, such as the one provided by Log4j, we could instead easily use Camel for that. Camel is really the best fit for such a thing, as we'd be able to add advanced things such as redelivery, batching, compression and choose easily the transport we want (JMS or plain TCP).

The OSGi EventAdmin service is also an important point for monitoring events in the OSGi runtime, as most of the OSGi services do publish events to it (Blueprint bundles events, bundle events, etc...). So this was another need for a camel component.

Given Camel 2.5 will be released soon, I did not want to destabilize trunk just before the release so I've committed them to a github fork for now.

Those two components are really easy to use:


<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">
<camelcontext xmlns="http://camel.apache.org/schema/blueprint">
<route>
<from uri="paxlogging:camel"/>
<to uri="stream:out"/>
</route>
</camelContext>
</blueprint>


In your Karaf installation, add the osgi:camel as a root appender, and you'll see events printed to the console, though not in a nice way, as the goal is really to send them over the wire.

For the event admin component, things are really easy too:

<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">
<camelcontext xmlns="http://camel.apache.org/schema/blueprint">
<route>
<from uri="eventadmin:*"/>
<to uri="stream:out"/>
</route>
</camelContext>
</blueprint>


The name of the consumer endpoint identifies which topic the endpoint will consume from. This component can also be used as a producer to actually publish events to the Event Admin.

I think those components still miss a bit of configuration, but they seem to be a great way to distribute log events and OSGi events to the outside world in a very powerful configurable way.

As usual, feedback welcome. I think those two components can have some real use case, so I'd like them to be put back into the Camel trunk for 2.6.

Wednesday, September 22, 2010

Introducing Cade, the Config ADmin Extender

The OSGi Alliance is working on enhancements to the OSGi ConfigAdmin and some of the experimentation have been unveiled by Peter Kriens in a recent blog. The point is I was in need for enhancing the Apache Karaf blueprint configurations to be more dynamic, for example to restart the SSH server if its configuration had changed.

So I decided to start hacking on this idea and create cade, the Config ADmin Extender. The project is really small and allows you to easily access OSGi configurations in a type-safe manner. It seems to work quite well, so I plan to start using it in Karaf for the various parts that need a bit of dynamism for handling configuration changes.

I haven't done any release yet, but I hope to do that really soon. The source code is Apache Licensed, so feel free to have a look and provide feedback.

Monday, September 06, 2010

RemoteOBR

Over the last months, I’ve been pondering over the use of OBR, the OSGi Bundle Repository. OBR describes resources (mostly OSGi bundles) in terms of capabilities and requirements. The OBR resolver is able to find the list of bundles needed to fulfill a given bundle requirements. This allows deploying a bundle and its required dependencies without caring too much about the exact dependencies being deployed. In addition, it takes into account the already locally installed bundles and thus reduces unneeded duplication of libraries in different versions.

When I started to use the Felix OBR repository earlier this year, I quickly ran into performance problems during both the parsing phase and the resolution phase. It was nearly unusable for repositories more than a few dozens of resources, which mean in real world scenarii. So I spent some time optimizing things a bit. I also enhanced the API to provide more meaningful informations and to allow more control over the resolution. That work has been released as part of the 1.6.x series of Felix BundleRepository.

One of the enhancement I made was the ability to have a more powerful query mechanism for resources. The goal was to be able to actually use OBR to help people find needed OSGi bundles. This is often one of the main problem people have when building OSGi applications in the integration space. The SpringSource guys have done a good job at providing their Enterprise Bundle Repository and Apache ServiceMix also regularly provide a bunch of OSGi bundles for third party libraries

The main problem with those repositories is that they tend to become huge (more than 7 Mb of xml), which means it takes a long time to download, parse and consumes a lot of memory once it has been parsed. If you use it on multiple JVMs, it becomes quickly a problem and a waste.

That’s when I started to think about the idea of a remote OBR repository. So here we are: I’ve created a small project named RemoteOBR at FuseSource Forge. This project decouples the client API from the real repository manager which is remotely queried using a REST protocol.

It’s not complete yet, but it is already usable, so I invite everyone to go the RemoteOBR website, download, try it and provide feedback.