Developing Applications with Red Hat build of Apache Camel for Quarkus

The easiest and most straightforward way to get the dependency versions right in a new project is to use one of the Quarkus tools:

These tools allow you to select extensions and scaffold a new Maven project.

The generated pom.xml will look similar to the following:

<project>
  ...
  <properties>
    <quarkus.platform.artifact-id>quarkus-bom</quarkus.platform.artifact-id>
    <quarkus.platform.group-id>com.redhat.quarkus.platform</quarkus.platform.group-id>
    <quarkus.platform.version>
        <!-- The latest 3.8.x version from https://maven.repository.redhat.com/ga/com/redhat/quarkus/platform/quarkus-bom -->
    </quarkus.platform.version>
    ...
  </properties>
  <dependencyManagement>
    <dependencies>
      <!-- The BOMs managing the dependency versions -->
      <dependency>
        <groupId>${quarkus.platform.group-id}</groupId>
        <artifactId>quarkus-bom</artifactId>
        <version>${quarkus.platform.version}</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
      <dependency>
        <groupId>${quarkus.platform.group-id}</groupId>
        <artifactId>quarkus-camel-bom</artifactId>
        <version>${quarkus.platform.version}</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
    </dependencies>
  </dependencyManagement>

  <dependencies>
    <!-- The extensions you chose in the project generator tool -->
    <dependency>
      <groupId>org.apache.camel.quarkus</groupId>
      <artifactId>camel-quarkus-sql</artifactId>
      <!-- No explicit version required here and below -->
    </dependency>
    ...
  </dependencies>
  ...
</project>

Which particular BOMs end up in the pom.xml file depends on extensions you have selected in the generator tool. The generator tools take care to select a minimal consistent set.

If you choose to add an extension at a later point that is not managed by any of the BOMs in your pom.xml file, you do not need to search for the appropriate BOM manually.

With the quarkus-maven-plugin you can select the extension, and the tool adds the appropriate BOM as required. You can also use the quarkus-maven-plugin to upgrade the BOM versions.

The com.redhat.quarkus.platform BOMs are aligned with each other which means that if an artifact is managed in more than one BOM, it is always managed with the same version. This has the advantage that application developers do not need to care for the compatibility of the individual artifacts that may come from various independent projects.

When combining camel-quarkus-bom with any other BOM, think carefully in which order you import them, because the order of imports defines the precedence.

I.e. if my-foo-bom is imported before camel-quarkus-bom then the versions defined in my-foo-bom will take the precedence. This might or might not be what you want, depending on whether there are any overlaps between my-foo-bom and camel-quarkus-bom and depending on whether those versions with higher precedence work with the rest of the artifacts managed in camel-quarkus-bom.

Extending org.apache.camel.builder.RouteBuilder and using the fluent builder methods available there is the most common way of defining Camel Routes. Here is a simple example of a route using the timer component:

import org.apache.camel.builder.RouteBuilder;

public class TimerRoute extends RouteBuilder {

    @Override
    public void configure() throws Exception {
        from("timer:foo?period=1000")
                .log("Hello World");
    }
}

Since Camel 3.0, you can use fluent builders also for defining Camel endpoints. The following is equivalent with the previous example:

import org.apache.camel.builder.RouteBuilder;
import static org.apache.camel.builder.endpoint.StaticEndpointBuilders.timer;

public class TimerRoute extends RouteBuilder {

    @Override
    public void configure() throws Exception {
        from(timer("foo").period(1000))
                .log("Hello World");
    }
}

In order to configure Camel routes, rests or templates in XML, you must add a Camel XML parser dependency to the classpath. Since Camel Quarkus 1.8.0, link:https://access.redhat.com/documentation/en-us/red_hat_build_of_apache_camel/4.4/html-single/red_hat_build_of_apache_camel_for_quarkus_reference/ #extensions-xml-io-dsl[camel-quarkus-xml-io-dsl] is the best choice.

With Camel Main, you can set a property that points to the location of resources XML files such as routes, REST DSL and Route templates:

camel.main.routes-include-pattern = routes/routes.xml, file:src/main/routes/rests.xml, file:src/main/rests/route-template.xml

<routes xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns="http://camel.apache.org/schema/spring"
        xsi:schemaLocation="
            http://camel.apache.org/schema/spring
            http://camel.apache.org/schema/spring/camel-spring.xsd">

    <route id="xml-route">
        <from uri="timer:from-xml?period=1000"/>
        <log message="Hello XML!"/>
    </route>

</routes>

The route XML should be in the simplified version like:

<rests xmlns="http://camel.apache.org/schema/spring">
    <rest id="greeting" path="/greeting">
        <get path="/hello">
            <to uri="direct:greet"/>
        </get>
    </rest>
</rests>

<routeTemplates xmlns="http://camel.apache.org/schema/spring">
    <routeTemplate id="myTemplate">
        <templateParameter name="name"/>
        <templateParameter name="greeting"/>
        <templateParameter name="myPeriod" defaultValue="3s"/>
        <route>
            <from uri="timer:{{name}}?period={{myPeriod}}"/>
            <setBody><simple>{{greeting}} ${body}</simple></setBody>
            <log message="${body}"/>
        </route>
    </routeTemplate>
</routeTemplates>

To configure routes with YAML, you must add the camel-quarkus-yaml-dsl dependency to the classpath.

With Camel Main, you can set a property that points to the location of YAML files containing routes, REST DSL and Route templates definitions:

camel.main.routes-include-pattern = routes/routes.yaml, routes/rests.yaml, rests/route-template.yaml

- route:
    id: "my-yaml-route"
    from:
      uri: "timer:from-yaml?period=1000"
      steps:
        - set-body:
            constant: "Hello YAML!"
        - to: "log:from-yaml"

- rest:
    get:
      - path: "/greeting"
        to: "direct:greet"

- route:
    id: "rest-route"
    from:
      uri: "direct:greet"
      steps:
        - set-body:
            constant: "Hello YAML!"

- route-template:
    id: "myTemplate"
    parameters:
      - name: "name"
      - name: "greeting"
        defaultValue: "Hello"
      - name: "myPeriod"
        defaultValue: "3s"
    from:
      uri: "timer:{{name}}?period={{myPeriod}}"
      steps:
      - set-body:
          expression:
            simple: "{{greeting}} ${body}"
      - log: "${body}"

- templated-route:
    route-template-ref: "myTemplate"
    parameters:
      - name: "name"
        value: "tick"
      - name: "greeting"
        value: "Bonjour"
      - name: "myPeriod"
        value: "5s"

In addition to support configuring Camel through properties, camel-quarkus-core allows you to use conventions to configure the Camel behavior. For example, if there is a single ExchangeFormatter instance in the CDI container, then it will automatically wire that bean to the LogComponent.

To access CamelContext just inject it into your bean:

import jakarta.inject.Inject;
import jakarta.enterprise.context.ApplicationScoped;
import java.util.stream.Collectors;
import java.util.List;
import org.apache.camel.CamelContext;

@ApplicationScoped
public class MyBean {

    @Inject
    CamelContext context;

    public List<String> listRouteIds() {
        return context.getRoutes().stream().map(Route::getId).sorted().collect(Collectors.toList());
    }
}

If you are used to @org.apache.camel.EndpointInject and @org.apache.camel.Produce from plain Camel or from Camel on SpringBoot, you can continue using them on Quarkus too.

The following use cases are supported by org.apache.camel.quarkus:camel-quarkus-core:

import jakarta.enterprise.context.ApplicationScoped;
import org.apache.camel.EndpointInject;
import org.apache.camel.FluentProducerTemplate;
import org.apache.camel.Produce;
import org.apache.camel.ProducerTemplate;

@ApplicationScoped
class MyBean {

    @EndpointInject("direct:myDirect1")
    ProducerTemplate producerTemplate;

    @EndpointInject("direct:myDirect2")
    FluentProducerTemplate fluentProducerTemplate;

    @EndpointInject("direct:myDirect3")
    DirectEndpoint directEndpoint;

    @Produce("direct:myDirect4")
    ProducerTemplate produceProducer;

    @Produce("direct:myDirect5")
    FluentProducerTemplate produceProducerFluent;

}

You can use any other Camel producer endpoint URI instead of direct:myDirect*.

The following use case is supported by org.apache.camel.quarkus:camel-quarkus-bean:

import jakarta.enterprise.context.ApplicationScoped;
import org.apache.camel.Produce;

@ApplicationScoped
class MyProduceBean {

    public interface ProduceInterface {
        String sayHello(String name);
    }

    @Produce("direct:myDirect6")
    ProduceInterface produceInterface;

    void doSomething() {
        produceInterface.sayHello("Kermit")
    }

}

Health & liveness checks are supported via the MicroProfile Health extension. They can be configured via the Camel Health API or via Quarkus MicroProfile Health.

All configured checks are available on the standard MicroProfile Health endpoint URLs:

We provide MicroProfile Metrics for exposing metrics.

Some basic Camel metrics are provided for you out of the box, and these can be supplemented by configuring additional metrics in your routes.

Metrics are available on the standard Quarkus metrics endpoint:

By default, not all Charsets are available in native mode.

Charset.defaultCharset(), US-ASCII, ISO-8859-1, UTF-8, UTF-16BE, UTF-16LE, UTF-16

If you expect your application to need any encoding not included in this set or if you see an UnsupportedCharsetException thrown in the native mode, please add the following entry to your application.properties:

quarkus.native.add-all-charsets = true

See also quarkus.native.add-all-charsets in Quarkus documentation.

By default, only the building JVM default locale is included in the native image. Quarkus provides a way to set the locale via application.properties, so that you do not need to rely on LANG and LC_* environement variables:

quarkus.native.user-country=US
quarkus.native.user-language=en

There is also support for embedding multiple locales into the native image and for selecting the default locale via Mandrel command line options -H:IncludeLocales=fr,en, H:+IncludeAllLocales and -H:DefaultLocale=de. You can set those via the Quarkus quarkus.native.additional-build-args property.

Resources accessed via Class.getResource(), Class.getResourceAsStream(), ClassLoader.getResource(), ClassLoader.getResourceAsStream(), etc. at runtime need to be explicitly listed for including in the native executable.

This can be done using Quarkus quarkus.native.resources.includes and quarkus.native.resources.excludes properties in application.properties file as demonstrated below:

quarkus.native.resources.includes = docs/*,images/*
quarkus.native.resources.excludes = docs/ignored.adoc,images/ignored.png

In the example above, resources named docs/included.adoc and images/included.png would be embedded in the native executable while docs/ignored.adoc and images/ignored.png would not.

resources.includes and resources.excludes are both lists of comma separated Ant-path style glob patterns.

Refer to Red Hat build of Apache Camel for Quarkus Extensions Reference for more details.

When using Camel onException handling in native mode, it is your responsibility to register the exception classes for reflection.

For instance, having a camel context with onException handling:

onException(MyException.class).handled(true);
from("direct:route-that-could-produce-my-exception").throw(MyException.class);

The class mypackage.MyException should be registered for reflection. For more information, see Registering classes for reflection.

By default, dynamic reflection is not available in native mode. Classes for which reflective access is needed, have to be registered for reflection at compile time.

In many cases, application developers do not need to care because Quarkus extensions are able to detect the classes that require the reflection and register them automatically.

However, in some situations, Quarkus extensions may miss some classes and it is up to the application developer to register them. There are two ways to do that:

If serialization support is requested via quarkus.camel.native.reflection.serialization-enabled, the classes listed in CamelSerializationProcessor.BASE_SERIALIZATION_CLASSES are automatically registered for serialization.

You can register more classes using @RegisterForReflection(serialization = true).

Quarkus supports generating resources for vanilla Kubernetes, OpenShift and Knative. Furthermore, Quarkus can deploy the application to a target Kubernetes cluster by applying the generated manifests to the target cluster’s API Server. For more information, see the Quarkus Kubernetes guide.

The Camel Quarkus extensions whose consumers support Knative deployment are:

Quarkus also supports the Service Binding Specification for Kubernetes to bind services to applications.

The following Camel Quarkus extensions can be used with Service Binding: