Guillaume Nodet's blog

From a high level, ZooKeeper can be seen as a replicated tree, and Fabric uses this tree to store the configuration of the various agents (we call Agent, any Karaf instance connected to the same Fabric cluster). Fabric defines a notion of profile, which is a "kind" of agent. We can define different profiles for various applications we want to deploy in Karaf, for example an ActiveMQ broker or a web server. A given agent can be assigned multiple profiles, allowing a single Karaf instance to serve multiple purposes. To configure a Karaf instance, Fabric uses the ConfigAdmin OSGi service which is the standard way to push configurations to OSGi applications. An agent will have a bundle deployed which will monitor the ZooKeeper tree and update the configurations according to the profiles it has been assigned. Each bundle will then automatically be notified of the changes through the ConfigAdmin service. It is often the case that configurations are mostly the same between sever...

I'm very pleased to introduce FuseSource Fabric , a distributed configuration, management and provisioning system for the products supported by FuseSource : Apache ServiceMix , Apache Camel , Apache ActiveMQ and Apache CXF . The user's guide contains lots of informations, so I won't rewrite it all again, but I instead invite you to have a quick look at it. The core Fabric is deployed on top of Apache Karaf and heavily reuses the very mature Apache ZooKeeper project. I'm really excited about Fabric. I've been working on it since Apache Karaf 2.2.0 has been released and I'm glad to share this work. I won't add much more for now, but stay tuned as I plan to write a number of posts explaining the various parts of Fabric.

I just want to point out the great conference FuseSource is sponsoring around open source integration and especially Apache Camel. Unfortunately, I won't be able to attend the event as my wife is expecting our sixth child in the coming weeks :-). That would have been a great opportunity to have my copy of the EIP book signed by Gregor though. You should definitely go there and listen to all the great speakers . Click on the image below for more informations.

I’ve been involved in ServiceMix, the Open Source ESB, nearly since its inception. ServiceMix was started by James Strachan and Rob Davies in May 2005 and the 1.0 version was released in August 2005. I joined LogicBlaze in October 2005 (leaving Mule behind, as I was a committer on Mule) to work on the 2.x releases (2.0 was released in November 2005) and then on the 3.x after the move from Codehaus to the Apache Software Foundation (3.0 was released in May 2007) and the 4.x versions based on OSGi (4.0 was released in March 2009). Even though I’m now focusing more on the OSGi side now (being the VP of Karaf), I’ve done my share of work on ServiceMix (I’m still the first committer in terms of number of commits according to http://svnsearch.org/svnsearch/repos/ASF/search?path=/servicemix) and I’ve been the VP of ServiceMix at the ASF for a few years. ServiceMix started as a very lightweight implementation of JBI spec. The 2.x version brought much more JBI compliance and the 3.x has se...

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/sch...

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.

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...