Camel in Action book outdated?

As you may know Jonathan and I got published about 1.5 years ago with the Camel in Action book.

And the book has been very well received within the community, and helped a lot of people getting onboard riding the Camel.

Jonathan and I have done our best to keep the material in the book as up to date to the lastest Camel release. In fact during the type setting period (that takes 4 months) we ensure that material was updated accordingly to new Apache Camel releases. So when the book went into production it was up to date with the Apache Camel 2.5.0 release from October 31st 2010.

Ever since the book was published we have been active on the Author Online forum to catch the minor mistakes and feedback you may have. The errata of the book is fully up to date. In fact the errata was updated as late of a couple of months ago.

Likewise the accompanying source code of the book has been kept up to date with the newer Camel releases, up till the lates official release 2.9.2 And this time we have prepared the source code for the upcoming Camel 2.10 release (currently expected to be GA next week).

Myself, as a reader of other books, this kind of service is rare. Most authors do not bother to even keep an errata, or make sure their source code actually works.

In fact we use the source code for the book as a test suite for the upcoming Apache Camel releases. In fact it was due to this source code we caught a regression in the 2.10 release, that we had to fix that and recut a new release candidate.

So with that in mind, its sad to see a reader post a bad review on Amazon (Click on image to read).

Our first 1-star review

For example the reader complains that he/she cannot find the Apache Camel 2.5.0 download. Well its due to Apache policy that older releases are not highlighted on the website, but available in the Apache Archives. If you click on the download link on the Camel website, we have a heading in the top saying "Older Releases". So its not hard to find.

You can download older Apache Camel releases

Riding the Camel with a new hat

This morning I woke up to the news out in the public that Red Hat to Acquire FuseSource.  You can read the Acquisition FAQ to learn more what has happened.

This is really great news for the FuseSource team, to find a new home that has truly Open Source in its DNA. Our new home is the JBoss Middleware Team, which are no strangers to what we do. JBoss loves our work we do in the Apache communities and they have been using the Apache products for many years. For example Apache Camel is part of the JBoss products. 

For me personally this means I can continue to do what I love; with my devoted effort in the Camel communities and on the Apache Camel project itself.

My colleague Charles Moulliard, got creative this morning, and gave the Camel a new hat.

The Camel got a new hat. Photo by Charles Moulliard.

I guess its time for me to get a new hat as well. 

Photo of Claus, not wearing a Red Hat (yet)

And I gathered a list of some blogs posted about this news from fellow employees

• James Strachan - Fuse Team acquired by Red Hat
• Rob Davies - We are now part of Red Hat
• Christian Posta - FuseSource acquired by Red Hat
• Lars Heinemann - FuseSource acquired by Red Hat
• Mark Little - Welcome FuseSource to the JBoss family

Locking down JMX naming now easier with Camel 2.10

The Apache Camel 2.10 is on the way. In fact this morning a RC has been cut. So expect 2.10 to be released soon.


This is a blog post I have had on my todo pad for a while meant to be written sooner. Anyway I got a bit of breather this morning, and wanted to get this done before the 2.10 is released.

Background

So the issue people may have is when they run many Camel applications in the same JVM, such as in Apache ServiceMix, Apache Karaf, Fuse ESB, Fuse ESB Enterprise, Fuse Fabric, and the classic web and JEE servers such as Apache Tomcat, Jetty, JBoss, et all. Its the JMX naming.


So in the JMV we have a default JMX server in which we enlist Camel MBeans, allowing you to manage and monitor Camel apps using JMX. As there is one JMX server, and multiple Camel applications, then we need to ensure the MBeans have unique ObjectName's so they dont clash. 


Apache Camel has out of the box a liberal strategy to cater for this, and in case of a clash, it will by default, auto remedy this by computing a unique name, using a counter based approach. 


For example this may give you ObjectNames with names that contains the counter in the name such as:
...camel-1/...
...camel-2/...
...camel-3/...


The default naming strategy is to use the CamelContext id (eg name) and apply the counter in case of clash. So if you use unique CamelContext id in your Camel applications, then you already have unique ObjectName's in the JMX, and thus no clashes.


The default strategy in OSGi containers is a bit different, as the naming is prepended with the bundle id, which gives us out of the box names such as

...76-camel-1/...
...77-camel-1/...
...78-camel-1/...

And in case you have multiple Camel applications in the *same* bundle, then the naming will use the counter, like for non OSGi environments

...76-camel-1/...

...76-camel-2/...

...76-camel-3/...

...77-camel-1/...
...78-camel-1/...

Okay you have read so far, this is good. So lets get to the point where things have improved in Camel 2.10, and what you can do in previous Camel releases.


The issues is that in OSGi containers, the bundle-id would by default always be prepended, so controlling the naming was a bit harder. What you can do to remedy this in previous Camel releases is to use a custom org.apache.camel.spi.ManagementNamingStrategy, allowing you full control of the namings of the ObjectName's. The problem is that you would then need to implement this interface and code an implementation. So what we have done in Camel 2.10 is to let you configure the naming using a pattern style, much more easily.


To see this in action, lets walk through an use-case.

Walking through an example

This example is created by using the Camel Maven archetype to create a new OSGi Blueprint project, using the camel-archetype-blueprint. This is a simple example that can easily be deployed in an OSGi container such as Apache Karaf. When the project is created, I can compile and build the artifact using mvn install.


I have a vanilla Apache Karaf 2.2.7 extracted, and start it using bin/karaf.

davsclaus:/opt/apache-karaf-2.2.7$ bin/karaf
        __ __                  ____      
       / //_/____ __________ _/ __/      
      / ,<  / __ `/ ___/ __ `/ /_        
     / /| |/ /_/ / /  / /_/ / __/        
    /_/ |_|\__,_/_/   \__,_/_/         


  Apache Karaf (2.2.7)


Hit '' for a list of available commands
and '[cmd] --help' for help on a specific command.
Hit '' or 'osgi:shutdown' to shutdown Karaf.


Installing Apache Camel in Karaf is now easier using the new chooseurl command as shown below:


karaf@root> features:chooseurl camel 2.10.0
adding feature url mvn:org.apache.camel.karaf/apache-camel/2.10.0/xml/features
karaf@root> features:install camel
karaf@root> 

After installing Camel I can install my application using:


karaf@root> osgi:install mvn:com.mycompany/blue/1.0
Bundle ID: 75


And then I can start the bundle by its id


karaf@root> osgi:start 75


And list the installed bundles


karaf@root> list
START LEVEL 100 , List Threshold: 50
   ID   State         Blueprint      Spring    Level  Name
[  64] [Active     ] [            ] [       ] [   50] camel-core (2.10.0)
[  65] [Active     ] [Created     ] [       ] [   50] camel-karaf-commands (2.10.0)
[  72] [Active     ] [            ] [       ] [   50] geronimo-jta_1.1_spec (1.1.1)
[  73] [Active     ] [            ] [       ] [   50] camel-spring (2.10.0)
[  74] [Active     ] [Created     ] [       ] [   50] camel-blueprint (2.10.0)
[  75] [Active     ] [Created     ] [       ] [   80] A Camel Blueprint Route (1.0.0)

Then I start JConsole to see the JMX tree

JMX name is 75-blueprintContext

My Camel application has been given bundle id 75, which mean out of the box the JMX ObjectName is pre-pended with 75.


Now the issue for some users, is that they may uninstall their applications, and then at a later time install the application again. So lets uninstall our application


karaf@root> osgi:uninstall 75

And then at a later time we install it again. Now the OSGi container will assign the bundle a new bundle id (as it will never re-use a previous bundle id). 


Notice: You can update/refresh your existing application, and keep the bundle id. Its only when you uninstall the bundle, that the bundle id, is discarded, and not used again.



karaf@root> osgi:install mvn:com.mycompany/blue/1.0
Bundle ID: 76
karaf@root> osgi:start 76


And if we see in JConsole we can see the Camel application now has a different JMX ObjectName.

JMX name is now 76-blueprintContext

So how can we control this JMX naming? Well in Camel 2.10 this is now much easier, ad we can define a naming pattern in our CamelContext directly.


There is a new managementNamePattern attribute in the as shown in the screenshot below. This pattern supports a number of tokens which we will cover in a second.

Camel 2.10 using the new managementNamePattern attribute

In this example we just want to use the CamelContext id as the JMX name, so we can use a token in the pattern, as shown using the #name# value. The following tokens is supported

• #camelId# = the CamelContext id (eg the name)
• #name# = same as #camelId#
• #counter# = an incrementing counter
• #bundleId# = the OSGi bundle id (only for OSGi environments)
• #symbolicName# = the OSGi symbolic name (only for OSGi environments)
• #version# = the OSGi bundle version (only for OSGi environments)

Besides the tokens you can use literals, so for example you can do managementNamePattern="foo-#symbolicName#" to have foo- as pre-prended value.

I then rebuild the project using mvn install, and from Karaf I update my application using:
karaf@root> osgi:update 76


And when I look in JConsole now, I can see the JMX naming is no longer having the bundleId prefixed.

JMX name is no longer having bundleId prefixed

The JMX naming is now locked down. This allows me for example to have any JMX capable monitoring tooling be configured once with the JMX ObjectName, and then be able to monitor my application in OSGi containers, regardless which bundle Id my application have been assigned.

Locked down JMX ObjectName

You can find some more details about JMX and Camel at the Apache documentation.

Runtime insight to Camel applications

My application is now running in Apache Karaf, and I can use the Camel Karaf commands to give me some details about my application, such as the context-info command telling me a bit about the uptime, and number of messages (is called exchanges) processed by Camel:

karaf@root> camel:context-info blueprintContext 
Camel Context blueprintContext
Name: blueprintContext
Version: 2.10.0
Status: Started
Uptime: 3 minutes
Exchanges Total: 39
Exchanges Completed: 39
Exchanges Failed: 0
Min Processing Time: 1ms
Max Processing Time: 366ms
Mean Processing Time: 11ms
Total Processing Time: 442ms
Last Processing Time: 3ms
Load Avg: 0.00, 0.00, 0.00
First Exchange Date: 2012-06-20 09:53:11
Last Exchange Completed Date: 2012-06-20 09:56:21



This is all text based, and using a tool such as Fuse IDE I can see all this in real time and visualized using EIP icons as shown below

Fuse IDE with real time visual insight of my running Camel applications in any JVM

Fuse IDE also allows me to see the installed bundles running in Apache Karaf. The bundles can be managed, for example I have stopped my blue application, indicated by the orange ball, which mean the bundle is not started, but in resolved state.

Fuse IDE can manage bundles running in the OSGi container

And know that I talk about Fuse IDE, then it has a nice terminal built-in. This is something that Windows users may struggle with normally, as they would need to use cygwin or something alike to SSH into remote machines. The terminal in Fuse IDE can connect to any remote box, or local running instances such as Apache Karaf.

Fuse IDE with SSH terminal to access Apache Karaf

Okay that's it for all the screenshot galore. Its time to go back to work. Have a nice day. And remember Apache Camel 2.10 is soon to be released, and its a killer release.

CamelOne 2012 Videos Freely Available

The CamelOne conference took place last month, which I have previously blogged about.

As promised by FuseSource, who was hosting the conference, all the presentations was video taped. And now those videos have been processed and made freely available on the CamelOne website.

Jonathan and I had the pleasure of doing a light keynote of how we got involved with the Apache Camel project, and talking about how the project have evolved over the years, and has been become so successful.

Claus and Jonathan, giving the keynote at CamelOne 2012

Since returning home, I have enjoyed watching the videos of the presentations I didn't have the pleasure to attend.

For example the FAA presentation about the SWIM program is mind blowing. One of their integration challenge is as follows

FAA SWIM integration challenge #3

And the solution is using Apache Camel, and drills down to basically 4 lines of logic

Solution to integration challenge #3

And no wonder FAA loves Apache Camel, they say ...

Yeah Camel Rocks!!!

In the FAA presentation you will see a live demo of their real time weather tracking program called SWIM. It has a fantastic Google Earth interface, so you can see a map of USA, and then drill down to the various airports and see how the weather impacts the flights.

There is a lot of great content in all the videos. And I encourage you to take a look. For example Robin Howlett, shows us how to use Camel and AWS together, and does live coding etc.

And if you are curious what Fuse Fabric is, then I suggest to look at the presentation from Ioannis, who is the lead architect on the project. And Hiram unlocks the mystery of the Apache Apollo, and why its such a great leap forward for the next generations of message brokers. And if you think HTML5 apps is the future, then I suggest o watch the presentation from Charles where he talks about Camel, ActiveMQ, websocket and HTML5 apps.

If you are getting started with Apache Camel, then you may wanna watch my presentation. Its a very practical presentation with a lot of live coding, and showing how you can get started with Camel from scratch.

Claus presenting and doing live coding

And there is a lot more. See for yourself at the CamelOne website.

FuseSource/Camel intro seminar in Copenhagen this week

Redpill Linpro, a FuseSource partner, is hosting a seminar on integration with Apache Camel, and the FuseSource products.

The event takes place in Copenhagen, on thursday june 14th at 8:30 to 11:30.
The location is very easy to find, as its just next to the Nørreport Metro station.

Frederiksborggade 15, 5th floot

You can find more details about the event here, registration is free.

Hope to see you there.