Guillaume Nodet's blog

Camel Endpoint DSL One of the new features of Camel 3.0  is an Endpoint DSL.  This new API aims to provide a type safe replacement for the URLs that are used in Camel to designate the consumer or producer endpoints.  These URLs provide 3 things: the scheme of the URL identifies the component to use, a unique name or id for the endpoint, and a set of parameters to customize the endpoint behavior. Here is an example of an FTP consumer endpoint definition: from( "ftp://foo@myserver?password=secret& recursive=true& ftpClient.dataTimeout=30000& ftpClientConfig.serverLanguageCode=fr" ) .to( "bean:doSomething" ); There are several drawbacks with such constructs : no type safety, bad readability and no simple completion. So we now use the meta model, which is currently extracted from the source using an annotation processor and written in various JSON files, to generate a fluent DSL for each endpoint.  The same...

It's Thanksgiving today and Apache Camel 3.0.0 has just been released, so I definitely want to thank the whole Camel community for the efforts put to get to this important achievement.  The Camel 3 work started a bit more than a year ago , so it's a 14 months effort that reaches its goal today.  But that's definitely not the end, as there's still a lot of work to do on Camel !  One thing to keep in mind is that Camel 2.0 was released in August 2009 , so a bit more than 10 years ago now. Part of this work was cleaning tons of things, components and apis, that were deprecated on this long lived 2.x branch.  Another part was modularization of the code base so that it can be used in more light weight scenarios.  We've created a migration guide to help people migrating their camel based applications.  There are also a lot of new features and we'll explore some of them in the following weeks.  My next blog entry will explore one of this new feature, the...

I want to give a bit more detailed explanations on some new stuff provided by the Karaf 4.x FeaturesService. Transitive closure The karaf-maven-plugin provides a new goal named verify .  It's an enhanced version of the previous validate goal.  This goal helps ensuring that all features are transitively closed with respect to their requirements.  This means that all the requirements for a given feature can be fulfilled without relying on already installed bundles or features.  This new goal actually uses the OSGi resolver to ensure that, so that it ensures your features can be deployed everywhere, without additional requirements. Viable deployments One of the new features I mentioned in my previous post is that the new Features service ensures that the features requirements are fully available.  When installing new features, this is usually not much of a problem, as we usually only add new bundles.  However, when uninstalling a feature, things ca...

Almost 3 years since I haven't blogged, so I'm using the fact that the Karaf 4.0 release in under vote to start again. Karaf 4.0 brings a lot of new features, but one of the most important one is the new features service.  It is originally a port of the Fuse/Fabric agent resolver to Karaf 4, but has since been extended a lot (and has actually been integrated back into Fuse 6.2). This new features services is used to install well known features, but even if it reuses the same features xml definition, it's not limited to those anymore and works in a very different way.  The main difference is that the original features service (in Karaf 2.x and 3.x) is quite blind when it comes to installing features.  When a user asks for a feature installation, the process was quite simplistic: the service mainly goes through the list of bundles listed in the feature and install them.  The introduction of the resolver flag brought some intelligence to the process, as the old and...

Yesterday, an important announcement was made: RedHat is acquiring FuseSource.  This news is following Progress announce a few weeks ago about FuseSource being divested as not being part of their new product strategy. This is truly exciting. RedHat looks like a fantastic company, pure Open Source players as we are too.  We will be integrated into the JBoss Enterprise Middleware Group and even if there is some overlap on the products, I don't have any doubts that we'll be able to find the best way to leverage our respective strengths to build new awesome products for our users and customers. This is definitely a good fit for both RedHat and FuseSource, and I'm definitely thrilled about it.

Je présente la semaine prochaine un webinar sur Camel en français intitulé "Introduction à Apache Camel". Inscrivez-vous !

I've released JLine 2.6 which should be available in central soon. The main change is that JLine is almost completely conform ant with GNU readline . This means that JLine will read the ~/.inputrc by default and now supports VI editing mode, macro recording and all the goodness you can find in your standard unix shell. It will be used in Karaf 3.0 and in the next Fuse ESB .

Last week, while in Vegas , I discussed with my colleague Scott Cranton and he told me that something that was really making our users tend to stick with Spring-DM when using Camel Blueprint routes was that unit testing those routes was not possible. So I hacked a small support library for Camel, leveraging PojoSR which provides a service registry without using a fully compliant OSGi container. This allows defining real unit tests (as opposed to integration tests using Pax Exam . See the below example. public class DebugBlueprintTest extends CamelBlueprintTestSupport { @Override protected Collection<URL> getBlueprintDescriptors() { return Collections.singleton(getClass().getResource("camelContext.xml")); } @Test public void testRoute() throws Exception { // set mock expectations getMockEndpoint("mock:a").expectedMessageCount(1); // send a message template.sendBody("direct:start...

I'm back from Las Vegas where we had a fantastic FuseSource KickOff meeting. As you can see below, a real camel had been brought from the west coast and James even had a short ride on it! On the technical side, we expect a bunch of exciting stuff this year, so you'll certainly hear from us soon.

Since the early days, Apache ServiceMix has had an implementation of the Oasis WS-Notification specifications. This implementation was built on top of Apache ActiveMQ and available inside the JBI bus as a service. Now that JBI is being put aside in ServiceMix, some questions arose about the future of this component. So last week, I took a stab at rewriting the component using pure JAX-WS services. For those that are not familiar with WS-Notification, this specification, unlike most other WS-* specifications defines a service described by a WSDL, so there's no low level protocol implementation to write. I took most of the code from ServiceMix implementation and just rewrote the JBI specific bits to leverage JAX-WS instead. The results have been committed into Apache CXF and should be part of the upcoming 2.5 release. Note that the implementation itself does not require CXF, though it can very well use it as the JAXWS provider. If you want to give it a try, you need to bu...

The Remote Services OSGi specification describes how services registered in an OSGi framework can be transparently accessed from another OSGi framework. This is in essence a remoting capability for OSGi services. Fabric has a very fast implementation of this specification, leveraging ZooKeeper for the discovery of services. From the user point of view, registering a service with a property service.exported.interfaces (with a value of ‘*’ or a list of classes to expose) is the only thing to do to make a service available from the outside. The Fabric DOSGi implementation will automatically detect which services have to be imported and will automatically create a proxy in the OSGi registry for those needed. This services to be imported are found through the use of Service Hooks which enable the implementation to be aware of which services are required by existing bundles. For example, if a bundle registers a ServiceListener (directly or indirectly by using Blueprint for example)...

Already, one month since my last blog entry, but time as been flying with the birth of my son Arthur a few weeks ago. I'd like to talk about the provisioning mechanism of Fabric a bit. In my last post, I explained how configuration was done through the use of ZooKeeper as the repository for configurations and profiles, propagated to various bundles using the OSGi ConfigurationAdmin service. The provisioning mechanism in Fabric is based on this mechanism: the fabric-agent bundle receives its configuration through the org.fusesource.fabric.agent pid and will automatically update bundles as needed. The nice thing is that the configurations are computed using an overlay mechanism which means that the list of bundles or features to deploy will come from the various profiles a give node has been assigned. The agent itself supports several kinds of informations: bundles that need to be installed karaf features that need to be installed repositories for karaf features a url poi...

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

Yesterday, the Apache Software Foundation established Karaf as a Top Level Project. It will take some time before the infrastructure resources are correctly set up, but you should see something at http://karaf.apache.org soon.