2016-05-01

Camel in Action 2 - One year later since we started

Its been a while since my last blog post or video.

I wanted to say some words about the progress of the work we do on the Camel in Action 2nd edition book.



I have noted in my calendar that I started writing the first words on Saturday March 7h 2015. Today one year later we are close to having 13 chapters done. Jonathan is finishing up the final touches on chapter 2. And yesterday I handed up my updates to the testing chapter to include a section covering Citrus Integration Testing with Camel.

All together on page counts, we have now surpassed the 1st edition which was 550 pages, and I estimate we are closing in on 600 pages. My last two chapters was rather long with about 70 pages each.

We are up for 2/3 round review where we will receive very valuable feedback from our readers. Thanks a lot. It really helps us steer the book in the right directions, and also help us focus on covering topics that are of the most interest.

There is still a many miles until we get to the finish line. But we are about to pass 66% and I am preparing for writing the chapter about microservices with Camel. I believe its a chapter that readers are looking forward to have in their hands.

Just a few words about writing a computer tech book. Its a lot of work besides the words on paper. At the same time we are building examples and providing source code for the book. And that do also take up a lot of time to do these code bits correct and of interest. We also spend time adding code comments and organizing the source code so you can browse the code on github, and quickly refer to where the code is being covered in detail in the book.

And you do this on a moving target. Apache Camel keeps marching on as usual, and we are very active working on the next release. At the same time Jonathan and I have to take notes about which of these changes/new features/etc are impacting the book. And then from time to time we have to circle back in past chapters and make updates accordingly.

So when you see that 10 out of 19 chapters are done in the Manning website. Then they are not done done. We are only done done when Manning tells us we are so, and that the book is heading into print. Well even so we are not done done, because after the book has been published, we keep updating the accompanying source code with future Camel releases. We have done that for 5 years since the 1st edition was published. Besides updates the source code we unfortunately may have mistakes slipping into the book, so with thanks from our readers, we have an errata to track those mistakes.

With the roads ahead of us I anticipate that Jonathan and I will have all the material ready in fall 2016, and the book enters type setting phase which is a process that Manning handles and that takes its time. That means the book will not be published in 2016, but in start of 2017.

Maybe at this time next year I can post a blog with the physical book in hand. That's gonna be a big big book. I estimate its going to be about 50% bigger than the 1st edition, so that is 800 pages.

2016-03-30

Help tell Pivotal to accept Apache Camel as a choice on start.spring.io

With the Apache Camel 2.17.0 release we have a camel-spring-boot-starter module that has the naming and convention that Spring Boot advises.

What would be good is to get Pivotal to add Apache Camel to the list of choices in the http://start.spring.io web application.

I have created a github PR with a screenshot of the web app showing Apache Camel.

Now to raise the voice of the community. The Camel users who would like to see this happen, should go to this PR

https://github.com/spring-io/initializr/issues/207

And then notice that thumbs up yellow icon that is just below the description (you may need to scroll a little bit down). Currently it has 27 votes.

To cast a vote then hover the mouse just next to the icon, and there should be a "add your reaction" showing you can click and select thumbs up.

In the PR there is also a screenshot you can look at what that would be like, which is also shown here below:

We want Apache Camel as a choice in start.spring.io !!!

2016-03-27

Apache Camel 2.17 Released

Apache Camel 2.17 has just been released.

This is the last release to support Java 1.7 which we have previously announced.

Here is a breakdown of the top noteworthy changes in this release (in random order).

1)
For OSGi users.

Reworked the Apache Karaf feature to not install camel-spring by default. The problem is camel-spring is using spring-dm which is only supports Spring 3.x, and therefore Spring 3.x was installed and used. All the Camel features that uses Spring JARs are now using Spring 4.x.

2)
SQL component can now load the SQL queries from external resources so you can use comments and format the queries using multi lines and indents.

In addition to that the SQL component now supports SQL IN queries where the IN values are dynamic calculated from the message body.

And there is also support for calling stored procedures using the sqlstored component.

3)
There is a new camel-spring-boot-starter module that works like any other Spring Boot starter module.

4)
The setHeader and setExchangeProperty allows to use a dynamic header key using the Simple language if the name of the key is a Simple language expression.

5)
Many improvements and fixes to Rest DSL among others

Rest DSL is Swagger API 2.0 compliant.

The Rest DSL now supports default values for query parameters

The Rest DSL now only binds from POJO to JSon/XML if the content-type is for json or xml. This allows you to specify a custom content-type and omit the binding, such as when having binary payloads.

Using CORS has been improved and fixed.

Swagger API can now generate YAML output as well as JSon.

6)
Avoid logging sensitive message body details.

Exchange and Message now only prints their id when their toString is called. Likewise the Camel Error Handler no longer log message body/header details when logging the Message History. There is an option you can turn this on again if wanted.

7)
Complete overhaul and rewrite of the camel-cdi module. Thanks to our new Camel rider Antonin Stefanuti.

The Camel CDI component has been improved to better fit into the CDI programming model, cover a larger set of containers, and provide these new features:

  • The Camel events from the org.apache.camel.management.event package (like CamelContextStartedEvent) can be observed as CDI events
  • The new CDI event Camel endpoint enable CDI events to be seamlessly consumed from (respectively produced by) Camel consumers (respectively Camel producers)
  • CDI beans annotated with the @Converter annotation are automatically registered as type converters
  • The CDI Camel contexts can be properly customized programmatically in bean constructor or @PostConstruct lifecycle callback
  • Camel routes configured in RouteBuilder beans are added before the corresponding Camel contexts get started
  • CDI Camel contexts are now properly adapted when deployed in OSGi containers and are registered as OSGi services
  • Proper support of multiple Camel contexts across all the features
  • A new Camel CDI Test module is available to ease testing of Camel CDI applications

8)
The camel-kafka module has migrated from using the Kafka Scala library to Kafka Java.

9)
The Loop EIP now allows to run in a while loop mode, so it loops until the predicate returns false.

10)
And as usual a bunch of new components. This time there is 12 new components and 4 new data formats.


For more details see the detailed release notes.

And any users who are upgrading then always read the bottom of the release notes about important changes to consider when upgrading.

You can download the release from Apache Camel website or from Maven Central if using Maven.



2016-03-24

Roadmap for Apache Camel 2.18 and towards Camel 3

The Camel team recently announced that Camel 2.17 would be the last release to support Java 1.7. And that the following release Camel 2.18 will require Java 1.8.

The numbers in the versions aligns very well to make it easy to remember:

  • Camel 2.17 = Java 1.7
  • Camel 2.18 = Java 1.8

So with Java 1.8 being the minimum Java version and that the code is compiled as 1.8 source brings in all the glory of Java 1.8 with aspects from functional programming with lambdas and whatnot.

Apache Camel has a huge community of existing Camel users, and we do not want to throw you guys under the bus, with massive Java 1.8 API changes in Apache Camel 2.18. Instead we see this release as a stepping stone towards more Java 1.8 readiness and the next major release Camel 3.0.

We have put up an open discussion in the Camel community on the developer mailing list, where you can read and participate. We love to hear feedback from the community.

You can read online using nabble where you can also post to the list. Or you can signup using old fashioned mailing list and write emails.

But what if you want to provide feedback elsewhere. Well I am sorry but Apache Software Foundation mandates openness and transparency. The discussions about the Apache Camel project must take place using ASF infrastructure such as the mailing list. However you are welcome to post a short comment on this blog, and I can post your comments on the mailing list on your behalf, if you are not arsed to signup on a mailing list, or register using nabble. However you do yourself a favor of signing up the Camel mailing list as there is a ton of information you can learn from other Camel users.

Just a word about Camel 3.0. The big goal for Camel 3.0 is less technical but more a new website and new documentation. And we would love to see a new project logo as well. The technical parts are sure there too, but its overdue for a modern website with documentation we maintain from the source code so its much easier and faster to keep it up to date. Also all the EIP and Component options is slurped from the source code to ensure the documentation is 100% in sync.


2016-02-26

Camel tools to add or edit endpoints from current cursor position

This is a continuation of the video blogs I have done about our development on the fabric8 Camel tools.

Today is friday so it was a chance to grab a beer and do a one take video recording. This time demonstrating how the Camel tools is able to from the cursor position in your Java editor such as IDEA or Eclipse to add or edit Camel endpoints in a type-safe way using a wizard. What is cool about the command is that you just put the cursor on the line with the endpoint to edit, or place the cursor where you want to add the endpoint.

The video is 7 minutes long and shows Eclipse and IDEA where I edit two different Camel projects. One project is using XML for declaring the Camel routes, and the other is using Java. The tools work with both kind.

So sit back and grab a beer and watch, or if you are in the office then maybe grab a coffee or tea.


We are working on doing the same for the EIP patterns and got that working for XML, but the Java bits is still pending. But down the road what you see in this video would be possible to across the board in Camel.




2016-01-29

Cheers - fabric8 Camel Maven Plugin to validate Camel endpoints from source code

Today I recorded a 12 minute video to demonstrate the new fabric8 camel-maven-plugin that is able to validate all your Camel endpoints from the source code. This allows to ensure your endpoints are valid before you run your Camel applications or unit tests. And it helps you catch those type errors or if you use invalid values for the options and so on.

video of fabric8 camel-maven-plugin in action
The fabric8 camel-maven-plugin can be run from within your Java editor as I demonstrate in the video, and of course from the command line. The plugin is able to parse both XML and Java code (the latter uses Eclipse JDT). So should be useful for all schools of Camel users.

We hope to improve on the plugin to have tighter integration in the editors such as IDEA and Eclipse, so you can have in-place Camel endpoint validation and code assistance while typing your Camel endpoints. We are working together with the JBoss Forge team to add the necessary hooks and apis that allows this plugin and the Camel forge commands to tie into that. 

Cheers and have a beer its the weekend soon, and yesterday Apache Camel 2.16.2 and hawtio 1.4.60 was released. That is a good excuse for grabbing a beer or a glass of wine.

2016-01-16

Apache Camel and other ESB products (Camel vs Mule) - 5 years later

Yesterday Raul Kripalani (a fellow Camel rider) posted a tweet:
Shoutout to @davsclaus & #Camel riders! Just added a reflection upon the last 5y on this SO question: https://stackoverflow.com/questions/3792519/apache-camel-and-other-esb-products/34818263#34818263 …. Have a look!
The tweet refers to an old question on stackoverflow about the Apache Camel versus other ESB, and this question is in particular about Camel vs Mule.

The question was asked in September 2010, and now fast forward 5+ years Raul took a look at the situation today. I think his detailed answer is worth attention for users of Camel, and others who are doing assessment on integration software.

Rauls answer starts out as shown below. I suggest to go read his post - after you have finished reading this blog ;). And you are welcome to use the upvote ;)


I think Raul has some major points to point out about the difference between Camel and Mule.

The key differentiator I see is, the non technical aspects, Apache Camel is:
  • 100% truly open source
  • Open community
  • Everything is discussed and happening in the open
  • Anyone can participate (and become a committer)
  • No control of a single vendor
  • All branding and marks belongs to ASF
  • ASF is a non-profit foundation where companies cannot control it
  • All code is open source and ASL licensed (no open-core/community vs enterprise model)
  • No vendor lock-in

An maybe overlocked fact is that the branding and marks of Apache Camel belongs to the ASF foundation. So no commercial company can "take the brand" and run with it. Neither Red Hat or Talend etc. can create a product called Red Hat Camel, Talend Camel ESB etc or some variation of the project name. Apache Camel is the authentic project.

Other projects may encounter such a problem. For example docker is very famous brand today, and there is no neutral foundation that owns that brand, the brand is owned by docker.inc (the company). So IMHO there is an interest of conflict with the brand name and docker.com the commercial company.

Another important aspect of Apache Camel (and ASF projects) is that there is no open-core/community vs enterprise model. At Apache Camel we would never deceive the community, for example by learning which Camel components that are the most popular and remove the source code from the community version and put that under a different license in a closed-source enterprise only product.

We from the Apache Camel project do neither spread/post FUD and eschewed marketing stunts on the Apache Camel website, unlike Mulesoft, where they are doing that by posting their controversial Mule vs Camel post on their commercial website. The piece of material smells of corporate bullshit, and no true honest developer would write such a piece of ...  (excuse my english)

And a final note Its also worth referring people to the previous blog, which also spun from a tweet where you can easily compare projects on blackduck, such as Camel vs Mule.



With Apache Camel it is all about the community, for the community, and all work is done in the open. Anyone can participate and we love contributions.

Roll on 2016 its going to be another great year for the Camels.