Apache Camel 2.3 will be yet another big win for the Camel community

When I glace over the progress of the Camel 2.3 on the in progress release notes, it tell me this is going to be a yet another great release. The Camel community is really stepping up and keep contributing to the Camel eco system. This time we are looking at approximately 10 new components, this may be a record high.

Martin Krasser keeps working on new features and components to the Camel Google App Engine, as well as his great work on the Camel Akka integration.

And this time we had a new component to the camel-core, which doesn't happen that often. Its the property placeholder component, which finally allows you to use placeholders in your Camel routes without having to use Spring Property Placeholder workarounds and whatnot.

We are also bringing in HawtDB which I am sure we will expand in the future. Currently its the persistent framework for the overhauled aggregator, so we can have those in flight aggregated messages in a safe persistent store.

Ashwin Karpe took the time to add camel-netty, which is great news for us that are starting to loose faith that Apache Mina 2.0 is ever going GA. When I got started with Camel, Mina 2.0 was in the works, and that is over 2 years ago.

Christian Mueller did really great and hard work to upgrade both camel-jetty and camel-http to use the latest stable releases of Jetty 7.0 and Apache Http Client 4.0.1. However in the latter case, we have recently decided to keep camel-http using the good old trusty Http Client 3.1, and let camel-http4 be the new playground for the Http Client 4.x, while it matures a bit more.

Christian didn't stop there and is now working on a camel JSR-303 component for bean validation, CAMEL-2565, which should make it in Camel 2.3 GA.

Mitko Kolev created a camel-exec component, so we can execute native applications. The component can then capture outputs from std out, err and whatnot. Really great work.

Christian Schneider created a camel-soap data format which allows you to marshal to/from SOAP without the need to bring in the guns with CXF or similar framework.

Stephen Gargan, contributed the camel-crypto component/data format. Now using javax.crypt has never been easier in Camel.

And the Camel itself, had many other significant wins as well, which I will safe for another time to do a blog entry.

And yes we need to have a couple of these new components documented on the wiki. It would be a shame if we have to pull out a new component from the release, just because, the contributed only contributed the code, but didn't do the necessary documentation as well.

As you know I have writing Camel up to both my ears with the book, so it must be the community who documents, what is contributed to the code base.

This is really outstanding work from the Camel community. A round of applause from your humble Camel rider.


Mitko said...

Hi Claus,
Maybe it is worth mentioning, that i have been writing the Camel Exec component documentation offline for a week, because i don't have a wiki account yet (I cant find my name under http://people.apache.org/~jim/committers.html#unlistedclas yet). In the next 1 or 2 days, I will submit a patch with the confluence content, so that you can get a release, with the Exec component, on time.


Claus Ibsen said...

Thanks Mitko for your contribution.

Unfortunately there has been a hacker attach at Apache recently, which means wiki edits is currently disabled.

But when its back online we can get the documentation added.

dulanov said...

It's very amazing feature - "We are also bringing in HawtDB which I am sure we will expand in the future. Currently its the persistent framework for the overhauled aggregator, so we can have those in flight aggregated messages in a safe persistent store."

But why not just to use BerkeleyDB for Java or badudb? I think it'll be more pragmatic and robust solution.

Claus Ibsen said...


Camel is very pluggable and flexible. You can provide your own org.apache.camel.spi.AggregationRepository of choice, for example if you want to use a RDBMS.

HawtDB is our out of the box choice as its lightweight, no setup needed, than telling it the file to use as store. Its a key/value centric which is much simpler than having to shoe horn data into a SQL structure.

We love contributions so if anyone, let say, build a JPA AggregationRepository, then we are likely to add that to camel-jpa as well :)

dulanov said...

Claus, I did't talk about SQL-centric embedded storages and JPA, all of them - BerkleyDB for Java and babudb are embedded key/value databases. I just worry about mature and stability of HawtDB and offer to see you on babudb, as alternative persistent engine for the aggregation component. It's just idea, not more =)

Claus Ibsen said...

Someone mentioned on twitter he wanted to give a go for a Cassandra store for Apache ActiveMQ.

We me see how that goes and do then get that into Camel as well.

Currently HawtDB is facing all the initial issues we encounter. Including issues in Camel in terms of the logic in the Aggregator. But its shaping up very well now.

Hiram and I nailed an issue today which cause the store to be out of order in some rare case on startup and killing it.