We begin where it all started back in summer 2008. The internal API in Camel had some spots that caused a bit of pain to work with from within the framework itself. For instance especially generics backfired. So we had to get rid of them in Camel 2.0 and only only keep it where it brings value.
The API changes was also needed to allow us to do some optimizations in the 2.x timeframe, such as minimizing some of the overhead when messages is passed from node to node during routing.
Then the framework itself had some package tangles that we needed to look at also. To help with this we are using the excellent tool Structure 101 by Headway Software. Its incredible which mistakes you can spot with this tool. I was able to even spot wrong classes for Log categories based on copy/paste mistakes. Using this tool we where able to restructure and remove the bad tangles.
And from a tooling perspective the API is more open to allow tooling to inspect and being able to alter routes at runtime. James Strachan has even added a REST API so it should be much easier for tooling to integrate than relying on for instance JMX.
Now the API is clean and crisp.
Below is an architecture overview diagram created with Structure 101 that shows the structure of Camel 2.0.Structure 101 can create all kind of diagrams and its easier to create great looking diagrams as its drag and drop editor is very intuitive. And you can compact/expand the packages to hide details. For instance we could compact the processor package to be a single box instead of showing the inner packages as the diagram above.
So what does the API restructure have as impact for Camel 1.x end users? That is a good question. You definitely need to migrate your code from 1.x to 2.0 as several key issues have changed. The list below is what I can remember from the top of my header at the time of writing this blog entry:
- Camel 2.0 uses the Apache Top Level Schema for namespaces, whereas Camel 1.x uses the old schema namespace
- Several DSL keywords have been renamed in Camel 2.0
- @deprecated code has been removed
- Some components have been renamed (albeit components not used often)
- ProducerTemplate has been tighten a bit regarding send vs. request
- Default error handler have changed to not use a dead letter queue if processing failed
We are sure that this API should suit us well over the next many releases.