Camel Endpoint DSL

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

Apache Camel 3.0.0 released !

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 endpoint

Additional considerations on the new Features service

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 can be a bit more complicat

Karaf 4.0 is about to be released !

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 deprec

FuseSource acquired by RedHat

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.

Camel Webinar

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

JLine 2.6

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 .