Camel in Action - Half way through

I thought it would be a good moment to sit down and write a little blog entry about how it goes with the Camel in Action book. What better moment to do that than sitting in Heathrow killing a couple of hours before before departing to the states for a business trip. I am exited as I get the chance to meet my fellow and talented co worker from the Fuse team.

It has been almost 7 months for me on the book in terms of writing. I started at full speed on the 4th of July which must be a date that our friends from the states can remember. A couple of months in the process Hadrian and I realized that we need to adjust the team. We invited Jonathan to join us which works great. He have already produced 2 full chapters and is up to speed on the third. This is impressive as he got the honor to rewrite the first chapter which is the hardest to write. All three of us have had a go at this chapter.

In terms on my end I have focused on some of the more technical heavier chapters which suits me fine. It's after all me who is responsible for some of the major overhaul, improvements and new features introduced in Camel 2.x. Yes I am sure to brain dump evert piece of information so you are sure to get the most up to date material in the book. For example I have amended the chapters several times during work on Camel 2.2 which have introduced some new features and improvements.

Two weeks ago we had our 2nd review completed. The review process is controlled by Manning and they do a great job finding a great bunch of people for the review panel. Its totally anonymous so we do get the word from the hearts. It's a mixed group of Camel experts, end users and authors whom have don't know Camel. I will get to what this 2nd review have had as impact on the book in a moment later.

We have also started the first copy editing process which means a professional editor from Manning is going over each and every chapter word by word, line by line, and checking that all add up. This is a remarkable work they do. We could start this work already since the 2 reviews have shown us that we are on the right track and the content so far in the book is great. Readers of my chapters will be glad to know that after the work of the copy editing the grammar and the flow in the language will be enjoyable to read. I am sorry but english is only my 2nd language.

Another impact the review and also you the readers of the book have had is that we have been in talks with Manning to extend the book with 2 new chapters. This is possible to do since the book have been received well so far. Thanks for all of you who have shown interest in the book. And especially you who have bought it. Its all thanks to you that we can include 2 new chapters to make the book cover Camel really really well.

We have already devoted one of the new chapters to cover concurrency, threading and the stuff associated with this. Its my next chapter when I have finished what is to become chapter 12 (monitoring and management).

As there are still one chapter to be decided what it should cover we have though to ask you. Of course we do have a couple of topics in mind but we would rather leave it totally open. So please if you have ideas then come along the Manning Author Online forum where we can discuss this.

At current time we have produced 7 chapters in a total of 250 pages which is available at the Manning MEAP program. That must be the half of 14 chapters, hence the block title.

Claus Ibsen
Heathrow, Terminal 5, B gates

Apache Camel in the cloud (GAE)

Martin Krasser our new and talented committer have crafted the camel-gae component with a very cool tutorial and demo application as well.

Now you can try this out as the Camel tutorial demo application is running in the cloud at Google.
You can get to the demo from this link: http://camelcloud.appspot.com

You can read more about the tutorial here (has screenshots).

Apache Camel 2.2 - Improved Test Kit

In this blog post I want to announce two new features in the Camel Test Kit which makes unit testing Camel routes easier. They are geared towards unit testing existing Camel routes where you may not use mocks or the likes. In other words testing production like routes.

The two features are:

• adviceWith
• NotifierBuilder

This blog post will cover the latter of the two. The reason is that I have yet to create wiki documentation for the former. So many things to do :)

NotifierBuilder

NotifierBuilder is as its name implies a builder which allows you to build an expression about a future condition where you want to be notified. Suppose you are doing integration testing and want to test when using a client API to send message, that those messages have been received and are routed as expected. Since we use a client API its not a Camel API which sends the message. Which means we have less control of this. And as we do not have mocks in the route we cannot easily know when or how the messages was routed. The NotifierBuilder helps you with this. Basically you build an expression which tells you, when this endpoint have received 3 messages and that endpoint have processed this special message then ring the bell.

A basic example

Lets start with a very basic example which just rings when one message has been processed.

NotifierBuilder notifier = new NotifierBuilder().whenDone(1).create();

client.sendMessages();

boolean done = notifier.matches(10, TimeUnit.SECONDS);

assertTrue("Should process the message within 10 seconds", done);

As you can see from this basic example, we created a notifier with the expression whenDone(1) which means that when 1 message has been processed. Then we use the client to send the messages or what ever it do to get the ball rolling. The point is that it may not be the Camel API sending in those messages.

Then we want to wait for the bell to ring, which we use the matches method on the notifier. To not wait forever we can pass in a timeout, which in this case is 10 seconds. Then we assert that a message was processed. Now we can do additional testing to verify the message was processed as expected. For example checking a database if the message was supposed to update something in it etc.

You are allows to invoke the matches method on the notifier as many times you want. So you can also use it to test that it should not match etc.

Another example

This is just a quick example to show the builder in action as it has many more methods to offer.

NotifierBuilder notifier = new NotifierBuilder()

        .from("jms:queue:orders").whenDone(5)

        .and().from("file:orders").whenDone(3)

        .and().from("jms:topic:audit").whenReceived(8)

        .create();

As you can see the builder allows you to stack expressions together which in this case we got 3 of them.

Combing the power with the Mock

You can even combine it with the power from the Camel Mock component, which allows you to use mocks for fine grained expectations. For example we expect those 3 messages to arrive in any order coming in on any JMS endpoint. 

MockEndpoint mock = getMockEndpoint("mock:foo");

mock.expectedBodiesReceivedInAnyOrder("Hello World", "Bye World", "Hi World");

NotifierBuilder notifier = new NotifierBuilder(context)

         .from("jms*").whenReceivedSatisfied(mock)

         .create();

To do this we can use the Mock for the fine grained expectations. The mock:foo is just a pseudo name as the route does not have any mocks for real. So you can give it any name you like. Notice how we use wildcard matching on the from to match any kind of JMS endpoint. Its the same wildcard matching as with the interceptors so you can use reg exp as well.

Want to learn more

You can read more about the NotifierBuilder and see which methods it currently offers at in the documentation. You can read in general about testing with Camel here.

And I also have to stress that chapter 6 in the Camel in Action book is devoted to the art of testing with Camel. So you got 35 good pages on this subject.

As its a new feature introduced in Camel 2.2 then we would of course improved it over time. And if you have ideas or feel a method in the builder is missing then let us know. And as always we love contributions and patches. And as always naming is hard, if you have better ideas for method names on the builder then again feedback is welcome.

Oh and the adviceWith is also a promising feature which I later will get documented as well. As always you can check out the source code to learn more :)

Update: NotifierBuilder has been renamed to NotifyBuilder. Which means the updated link to the documentation will be http://camel.apache.org/notifybuilder.html when the Apache wiki is synched.

Apache Camel - 2009 in numbers

Now we are all safe into 2010 I hope.

Just to do a quick post on some of the numbers for the Apache Camel project in year 2009.

Number of posts on Camel user forum in 2009: 5634
Number of commits in 2009: 4947 (commit mails send to public forum).
Number of tickets created in 2009: 1115 (where as 123 are still unresolved).
Number of tickets resolved in 2009: 1447
Number of tickets updated in 2009 but still unresolved: 149
Number of unresolved tickets not updated in 2009 or later: 2

I am sure you can dig more numbers if you got the time to hunt them down.

From the numbers I notice that we resolved more tickets in 2009 than created which means we are up-to-date with the issues reported. In fact there are only 146 (6%) open tickets currently. And for people reporting tickets we are surely bound to take a look as there are only 2 tickets which was not updated in 2009 at all. These 2 tickets are old tickets about a Groovy DSL and supporting Spring property placeholders. The latter is not possible due limitations in Spring Framework itself. The former is not in much demand. And you can already use Groovy for Camel DSL. So in case you have any issue with Camel we have a positive track record of looking into it.

Are there any numbers you would like to look at? Ohloh got some numbers for LOC and whatnot. It does however not have a solid history as Ohloh could not cope with the Apache Top Level Move we did in early 2009 so some of the metrics are not accurate.