Apache Camel 2.16 was released last friday.
This blog entry is my attempt to do a top-10 (+ 1 as bonus) highlights of this new release.
1. Dynamic To
Very likely the
top FAQ question from Camel users, is how do I send a message to an endpoint which uri should use a dynamic value from my message such as a header.
Up until this release the answer would be the recipient list EIP.
But to make this easier we introduced a dynamic to in the DSL that uses the simple language for dynamic computed endpoint uri, and sends the message to that single endpoint. For more advanced use-cases the answer is still recipient list, as it can send to multiple endpoints, in parallel, and do aggregation and much more.
So the
example from the FAQ
.to("freemarker:
Where the solution with recipient list would be:
.recipientList(simple("freemarker:
Can now easily be done using toD
.toD("freemarker:
In XML DSL you would use
We made to and toD separated on purpose. As the former allows Camel to optimize as it knows its a static endpoint, and the latter is dynamic.
The dynamic to is also supported in a few other EIPs such as WireTap, and in the
rest-dsl.
2. Enrich and PollEnrich now supports dynamic endpoints.
Because of the new dynamic to, with toD, it made headway for being able to introduce this into the Content Enricher EIPs for enrich and pollEnrich. This has been on popular demand for a number of years, but was initially planned as a Camel 3.0 change. This works as toD does by supporting the simple language in the URI.
A little example:
from("direct:start")
.enrich().simple("http:myserver/${header.orderId}/order")
.to("direct:result");
|
Notice how we can refer to the header using ${header.orderId}.
3. All inclusive Component documentation
We have 199 components (some are variations such as ftp sftp etc) in this release. And for every single option you can configure on the component or the endpoint is now documented with javadoc.
That documentation is then extracted during the build process which makes it available at runtime, which you can access using Java API, JMX, or the
Camel commands.
We have also started the process to label (think as a tag/badge) each option so you can see whether the option is for consumer, producer, security, advanced, and so on. This is an ongoing process, but we have done this for the components that has the most options.
This is a a continuation of the effort we started all way back in Camel 2.12. The previous Camel 2.15 release had a lot of documentation, which
I have blogged about. With Camel 2.16 we now have 100% coverage of the documentation, and we have enabled a validation check during the build that will fail of options lack documentation.
With this functionality tooling such as
hawtio can make beautify UI to present information about your Camel application such as shown below:
 |
| hawtio shown at runtime endpoint properties how its configured. The options is grouped in tabs. |
4. More deep level JMX statistics
We have overhauled all the EIPs to offer more runtime statistics about the EIPs. For example the Content Based Router now allows to list all the predicates, and break-down which of these predicates have been used the most. The load balancer EIPs also exposes statistics such as their current state, which exception has been triggered the most, and so on. That goes around for all the various EIPs. In addition the configuration of the EIP is also exposed.
We also managed to make it possible to have your custom Camel components or Java Beans mixin their custom JMX attributes and operations together with the standard set of attributes/operations from Camel. Before that was not possible and it would be only yours that was available. I have
blogged about this previously.
5. Incoming and Outgoing Endpoints
We now keep track of all the incoming and outgoing endpoints in the endpoint registry. The registry is accessible from Java, JMX, and the Camel commands. The registry also keep track of how often each endpoint is in use, so you can know which ones are the most in use.
I have
previously blogged about this, and recorded a video to demonstrate this in action.
6. Swagger 2.0 in pure Java
The swagger component has been ported to Java as a new camel-swagger-java module, and upgraded to the swagger 2.0 spec. We also integrated the camel-swagger-java to the rest-dsl, and being able to use the selected HTTP component of choice. So if you use jetty with rest-dsl then the swagger module can reuse that for exposes the api docs over HTTP. The old module that is Scala based is deprecated and was only able to expose the api docs using a servlet.
I have
previously blogged about this and recorded a video of this in action.
7. rest-dsl improvements
You can now configure documentation for the parameter mapping of the rest service, for query parameters, path, body, and so on.
You can find more details from
a little example that is shipped in Apache Camel.
8. Script DSL
We introduced a dedicated
script in the DSL, to allow executing a script during routing, which by default does not modify your message. We found a number of users wanting to do this, but had a bit pain to use the language component and remember to set transform=false. With the script DSL it stands out in the route.
A little example to run some groovy script
<route>
<script>
<groovy>// some groovy code goes here</groovy>
</script>
<beanRef ref="myServiceBean" method="processLine"/>
</route>
|
9. Camel proxy easier to use with parameter binding enabled
If you use Camel proxy to hide middleware behind an interface, then when invoking the method(s) on the interface, now performs parameter binding up-front. We found out this is more intuitive and allows to map to these parameters from the message body/headers etc, just as you would do with the bean component.
See more detail at
Camel proxy.
10. A few other great new stuff
The file consumer now supports a read lock mode using idempotent. This allows safely to have clustered file consumers compete a shared file system for the same files, to ensure exclusive read lock controlled by a idempotent repository of choice, for example using hazelcast.
We also provides Maven archetypes for creating microservice style using spring-boot and cdi.
The aggregator supports a pre completion mode that allows the incoming message to complete previous group and start a new group with itself as the first message.
11. More components
There is 12 new components, and 3 new data formats.
- camel-paho - For MQTT messaging using Eclipse Paho client
- camel-pdf - For creating PDF documents
- camel-grape - allows you to fetch, load and manage additional jars when CamelContext is running.
- camel-slack - allows you to connect to an instance of Slack and delivers a message contained in the message body via a pre established Slack incoming webhook.
- camel-jolt - for JSON to JSON transformation
- camel-aws-ec2 - Component providing support to Amazon Web Services EC2
- camel-undertow - To use Undertow as HTTP server or client.
- camel-git - A generic Git component
- camel-sjms - SJMS Batch is a specialized component for highly performant, transactional batch consumption from a JMS queue
- camel-http-common - A common base component for reuse among all the various HTTP components we have.
- camel-swagger-java - A pure Java based Swagger component.
- camel-elsql - An extended SQL Component that uses ElSql for defining SQL queries
- camel-jbpm - Sends messages through kie-remote-client API to jBPM.
For example there is a generic git component, a pdf component to output PDF documents, and a new batching JMS component that allows to batch X number of JMS messages and aggregate them into a single message all within a transactional boundary.
For a detailed list of changes in this release, see the
Camel 2.16 release notes. As always make sure to read the
important changes to consider when upgrading section, when you are upgrading from an older Camel release.
