Apache Camel - DSL

Camel uses a Java Domain Specific Language or DSL for creating Enterprise Integration Patterns or Routes in a variety of domain-specific languages (DSL) as listed below.

• Java DSL - A Java based DSL using the fluent builder style.
• Spring XML - A XML based DSL in Spring XML files
• Blueprint XML - A XML based DSL in OSGi Blueprint XML files
• Groovy DSL - A Groovy based DSL using Groovy programming language
• Scala DSL - A Scala based DSL using Scala programming language
• Annotation DSL - Use annotations in Java beans.
• Kotlin DSL - Work in progress - Currently developed outside ASF, but will we included later in Camel when Kotlin and the DSL is ready.

The main entry points for the DSL are

• CamelContext for creating a Camel routing rulebase
• RouteBuilder for creating a collection of routes using the routing DSL

See Also

For more examples of the DSL in action see

• Enterprise Integration Patterns
• Examples
• Routes

Apache Camel offers a Java based DSL using the fluent builder style. The Java DSL is available by extending the RouteBuilder class, and implement the configure method.

This is best illustrate by an example. In the code below we create a new class called MyRouteBuilder that extends theorg.apache.camel.builder.RouteBuilder from Camel.
In the configure method the Java DSL is at our disposal.

import org.apache.camel.builder.RouteBuilder;   /**  * A Camel Java DSL Router  */ public class MyRouteBuilder extends RouteBuilder {       /**      * Let's configure the Camel routing rules using Java code...      */     public void configure() {           // here is a sample which processes the input files         // (leaving them in place - see the 'noop' flag)         // then performs content based routing on the message using XPath         from("file:src/data?noop=true")             .choice()                 .when(xpath("/person/city = 'London'"))                     .to("file:target/messages/uk")                 .otherwise()                     .to("file:target/messages/others");     }   }

In the configure method we can define Camel Routes. In the example above we have a single route, which pickup [File]s, (eg the from).

from("file:src/data?noop=true")

Then we use the Content Based Router (eg the choice) to route the message depending if the person is from London or not.

.choice()     .when(xpath("/person/city = 'London'"))         .to("file:target/messages/uk")     .otherwise()         .to("file:target/messages/others");

Routes

Camel supports the definition of routing rules using a Java DSL (domain specific language) which avoids the need for cumbersome XML using aRouteBuilder.

For example a simple route can be created as follows.

RouteBuilder builder = new RouteBuilder() {     public void configure() {         errorHandler(deadLetterChannel("mock:error"));           from("direct:a").to("direct:b");     } };

As you can see from the above Camel uses URIs to wire endpoints together.

URI String formatting

Available as of Camel 2.0

If you have endpoint URIs that accept options and you want to be able to substitute the value, e.g. build the URI by concat the strings together, then you can use the java.lang.String.format method. But in Camel 2.0 we have added two convenient methods in the Java DSL so you can do fromF and toF that uses String formatting to build the URI.

from("direct:start").toF("file://%s?fileName=%s", path, name);   fromF("file://%s?include=%s", path, pattern).toF("mock:%s", result);

Filters

You can combine simple routes with filters which can be arbitrary Predicate implementations.

RouteBuilder builder = new RouteBuilder() {     public void configure() {         errorHandler(deadLetterChannel("mock:error"));           from("direct:a")             .filter(header("foo").isEqualTo("bar"))                 .to("direct:b");     } };

Choices

With a choice you provide a list of predicates and outcomes along with an optional default otherwise clause which is invoked if none of the conditions are met.

RouteBuilder builder = new RouteBuilder() {     public void configure() {         errorHandler(deadLetterChannel("mock:error"));           from("direct:a")             .choice()                 .when(header("foo").isEqualTo("bar"))                     .to("direct:b")                 .when(header("foo").isEqualTo("cheese"))                     .to("direct:c")                 .otherwise()                     .to("direct:d");     } };

Using a custom processor

Here is an example of using a custom Processor

myProcessor = new Processor() {     public void process(Exchange exchange) {         log.debug("Called with exchange: " + exchange);     } };   RouteBuilder builder = new RouteBuilder() {     public void configure() {         errorHandler(deadLetterChannel("mock:error"));           from("direct:a")             .process(myProcessor);     } };

You can mix and match custom processors with filters and choices.

RouteBuilder builder = new RouteBuilder() {     public void configure() {         errorHandler(deadLetterChannel("mock:error"));           from("direct:a")             .filter(header("foo").isEqualTo("bar"))                 .process(myProcessor);     } };

Interceptors

Here is an example of adding a few custom InterceptorProcessor objects to a processing pipeline:

RouteBuilder builder = new RouteBuilder() {     public void configure() {         errorHandler(deadLetterChannel("mock:error"));           from("direct:a")             .filter(header("foo").isEqualTo(123))                 .to("direct:b");     } };

When you start defining and interceptor stack with intercept(), you must follow up with the subsequent .target() so that the target of the interceptor stack is properly registered.

See Also

• DSL
• Examples