Getting Started with Camel Spring Boot

The curated camel-spring-boot-dependencies BOM, which is generated, contains the adjusted JARs that both Spring Boot and Apache Camel use to avoid any conflicts. This BOM is used to test camel-spring-boot itself.

Spring Boot users may choose to use pure Camel dependencies by using the camel-spring-boot-bom that only has the Camel starter JARs as managed dependencies. However, this may lead to a classpath conflict if a third-party JAR from Spring Boot is not compatible with a particular Camel component.

Each starter lists configuration parameters you can configure in the standard application.properties or application.yml files. These parameters have the form of camel.component.[component-name].[parameter]. For example to configure the URL of the MQTT5 broker you can set:

camel.component.paho-mqtt5.broker-url=tcp://localhost:61616

Camel routes are detected in the Spring application context, for example a route annotated with org.springframework.stereotype.Component will be loaded, added to the Camel context and run.

import org.apache.camel.builder.RouteBuilder;
import org.springframework.stereotype.Component;

@Component
public class MyRoute extends RouteBuilder {

    @Override
    public void configure() throws Exception {
        from("...")
            .to("...");
    }

}

Apache Camel ships a Spring Boot Starter module that allows you to develop Spring Boot applications using starters. There is a sample application in the source code also.

To use the starter, add the following to your spring boot pom.xml file:

<dependency>
    <groupId>org.apache.camel.springboot</groupId>
    <artifactId>camel-spring-boot-bom</artifactId>
    <version>3.20.1.redhat-00064</version> <!-- use the same version as your Camel core version -->
</dependency>

Then you can just add classes with your Camel routes such as:

package com.example;

import org.apache.camel.builder.RouteBuilder;
import org.springframework.stereotype.Component;

@Component
public class MyRoute extends RouteBuilder {

    @Override
    public void configure() throws Exception {
        from("timer:foo").to("log:bar");
    }
}

Then these routes will be started automatically.

You can customize the Camel application in the application.properties or application.yml file.

When using spring-boot with Spring Boot make sure to use the following Maven dependency to have support for auto configuration:

<dependency>
  <groupId>org.apache.camel.springboot</groupId>
  <artifactId>camel-spring-boot-starter</artifactId>
  <version>3.20.1.redhat-00064</version> <!-- use the same version as your Camel core version -->
</dependency>

The most important piece of functionality provided by the Camel auto-configuration is the CamelContext instance. Camel auto-configuration creates a SpringCamelContext for you and takes care of the proper initialization and shutdown of that context. The created Camel context is also registered in the Spring application context (under the camelContext bean name), so you can access it like any other Spring bean.

@Configuration
public class MyAppConfig {

  @Autowired
  CamelContext camelContext;

  @Bean
  MyService myService() {
    return new DefaultMyService(camelContext);
  }

}

Camel auto-configuration collects all the RouteBuilder instances from the Spring context and automatically injects them into the provided CamelContext. This means that creating new Camel routes with the Spring Boot starter is as simple as adding the @Component annotated class to your classpath:

@Component
public class MyRouter extends RouteBuilder {

  @Override
  public void configure() throws Exception {
    from("jms:invoices").to("file:/invoices");
  }

}

Or creating a new route RouteBuilder bean in your @Configuration class:

@Configuration
public class MyRouterConfiguration {

  @Bean
  RoutesBuilder myRouter() {
    return new RouteBuilder() {

      @Override
      public void configure() throws Exception {
        from("jms:invoices").to("file:/invoices");
      }

    };
  }

}

Spring Boot auto-configuration automatically connects to Spring Boot external configuration (which may contain properties placeholders, OS environment variables or system properties) with the Camel properties support. It basically means that any property defined in application.properties file:

route.from = jms:invoices

Or set via system property:

java -Droute.to=jms:processed.invoices -jar mySpringApp.jar

can be used as placeholders in Camel route:

@Component
public class MyRouter extends RouteBuilder {

  @Override
  public void configure() throws Exception {
    from("{{route.from}}").to("{{route.to}}");
  }

}

If you want to perform some operations on CamelContext bean created by Camel auto-configuration, register CamelContextConfiguration instance in your Spring context:

@Configuration
public class MyAppConfig {

  @Bean
  CamelContextConfiguration contextConfiguration() {
    return new CamelContextConfiguration() {
      @Override
      void beforeApplicationStart(CamelContext context) {
        // your custom configuration goes here
      }
    };
  }

}

The method beforeApplicationStart will be called just before the Spring context is started, so the CamelContext instance passed to this callback is fully auto-configured. If you add multiple instances of CamelContextConfiguration into your Spring context, each instance is executed.

Camel auto-configuration provides pre-configured ConsumerTemplate and ProducerTemplate instances. You can simply inject them into your Spring-managed beans:

@Component
public class InvoiceProcessor {

  @Autowired
  private ProducerTemplate producerTemplate;

  @Autowired
  private ConsumerTemplate consumerTemplate;

  public void processNextInvoice() {
    Invoice invoice = consumerTemplate.receiveBody("jms:invoices", Invoice.class);
    ...
    producerTemplate.sendBody("netty-http:http://invoicing.com/received/" + invoice.id());
  }

}

By default, consumer templates and producer templates come with the endpoint cache sizes set to 1000. You can change these values by modifying the following Spring properties:

camel.springboot.consumer-template-cache-size = 100
camel.springboot.producer-template-cache-size = 200

Camel auto-configuration registers a TypeConverter instance named typeConverter in the Spring context.

@Component
public class InvoiceProcessor {

  @Autowired
  private TypeConverter typeConverter;

  public long parseInvoiceValue(Invoice invoice) {
    String invoiceValue = invoice.grossValue();
    return typeConverter.convertTo(Long.class, invoiceValue);
  }

}

@Component
public class InvoiceProcessor {

  @Autowired
  private TypeConverter typeConverter;

  public UUID parseInvoiceId(Invoice invoice) {
    // Using Spring's StringToUUIDConverter
    UUID id = invoice.typeConverter.convertTo(UUID.class, invoice.getId());
  }

}

Camel applications which have this feature enabled launch a new thread on startup for the sole purpose of keeping the application alive by preventing JVM termination. This means that after you start a Camel application with Spring Boot, your application waits for a Ctrl+C signal and does not exit immediately.

The controller thread can be activated using the camel.springboot.main-run-controller to true.

camel.springboot.main-run-controller = true

Applications using web modules (for example, applications that import the org.springframework.boot:spring-boot-web-starter module), usually don’t need to use this feature because the application is kept alive by the presence of other non-daemon threads.

By default, you can put Camel XML routes in the classpath under the directory camel, which camel-spring-boot will auto-detect and include. You can configure the directory name or turn this off using the configuration option:

# turn off
camel.springboot.routes-include-pattern = false

# scan only in the com/foo/routes classpath
camel.springboot.routes-include-pattern = classpath:com/foo/routes/*.xml

The XML files should be Camel XML routes (not <CamelContext>) such as:

<routes xmlns="http://camel.apache.org/schema/spring">
    <route id="test">
        <from uri="timer://trigger"/>
        <transform>
            <simple>ref:myBean</simple>
        </transform>
        <to uri="log:out"/>
    </route>
</routes>

For testing, Maven users will need to add the following dependencies to their pom.xml:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-test</artifactId>
    <version>2.7.12</version> <!-- Use the same version as your Spring Boot version -->
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>org.apache.camel</groupId>
    <artifactId>camel-test-spring-junit5</artifactId>
    <version>3.20.1.redhat-00031</version> <!-- use the same version as your Camel core version -->
    <scope>test</scope>
</dependency>

To test a Camel Spring Boot application, annotate your test class(es) with @CamelSpringBootTest. This brings Camel’s Spring Test support to your application, so that you can write tests using Spring Boot test conventions.

To get the CamelContext or ProducerTemplate, you can inject them into the class in the normal Spring manner, using @Autowired.

You can also use camel-test-spring-junit5 to configure tests declaratively. This example uses the @MockEndpoints annotation to auto-mock an endpoint:

@CamelSpringBootTest
@SpringBootApplication
@MockEndpoints("direct:end")
public class MyApplicationTest {

    @Autowired
    private ProducerTemplate template;

    @EndpointInject("mock:direct:end")
    private MockEndpoint mock;

    @Test
    public void testReceive() throws Exception {
        mock.expectedBodiesReceived("Hello");
        template.sendBody("direct:start", "Hello");
        mock.assertIsSatisfied();
    }

}

Internally, every starter is configured through Spring Boot’s ConfigurationProperties. Each configuration parameter can be set in various ways (application.[properties|json|yaml] files, command line arguments, environments variables etc.). Parameters have the form of camel.[component|language|dataformat].[name].[parameter]

For example to configure the URL of the MQTT5 broker you can set:

camel.component.paho-mqtt5.broker-url=tcp://localhost:61616

Or to configure the delimeter of the CSV dataformat to be a semicolon(;) you can set:

camel.dataformat.csv.delimiter=;

Camel will use the Type Converter mechanism when setting properties to the desired type.

You can refer to beans in the Registry using the #bean:name:

camel.component.jms.transactionManager=#bean:myjtaTransactionManager

The Bean would be typically created in Java:

@Bean("myjtaTransactionManager")
public JmsTransactionManager myjtaTransactionManager(PooledConnectionFactory pool) {
    JmsTransactionManager manager = new JmsTransactionManager(pool);
    manager.setDefaultTimeout(45);
    return manager;
}

Beans can also be created in configuration files but this is not recommended for complex use cases.

Starters can also be created and configured via Spring Beans. Before creating a starter , Camel will first lookup it up in the Registry by it’s name if it already exists. For example to configure a Kafka component:

@Bean("kafka")
public KafkaComponent kafka(KafkaConfiguration kafkaconfiguration){
    return ComponentsBuilderFactory.kafka()
                        .brokers("{{kafka.host}}:{{kafka.port}}")
                        .build();
}

The Bean name has to be equal to that of the Component, Dataformat or Language that you are configuring. If the Bean name isn’t specified in the annotation it will be set to the method name.

Typical Camel Spring Boot projects will use a combination of external configuration and Beans to configure an application. For more examples on how to configure your Camel Spring Boot project, please see the example repository.

This plugin can be added to your Maven pom.xml file by adding it to the plugins section, for example in a Spring Boot application:

<build>
  <plugins>
    <plugin>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-maven-plugin</artifactId>
    </plugin>

    <plugin>
      <groupId>org.apache.camel</groupId>
      <artifactId>camel-restdsl-openapi-plugin</artifactId>
      <version>{CamelCommunityVersion}</version>
    </plugin>

  </plugins>
</build>

The plugin can then be executed using its prefix camel-restdsl-openapi as shown below.

$mvn camel-restdsl-openapi:generate

The goal of the Camel REST DSL OpenApi Maven Plugin is used to generate REST DSL RouteBuilder implementation source code from Maven.

The plugin supports the following options which can be configured from the command line (use -D syntax), or defined in the pom.xml file in the configuration tag.

If the Maven project is a Spring Boot project and restConfiguration is enabled and the servlet component is being used as REST component, then this plugin will autodetect the package name (if packageName has not been explicitly configured) where the @SpringBootApplication main class is located, and use the same package name for generating Rest DSL source code and a needed CamelRestController support class.

Works as generate goal but also generates DTO model classes by automatic executing the swagger-codegen-maven-plugin to generate java source code of the DTO model classes from the OpenApi specification.

This plugin has been scoped and limited to only support a good effort set of defaults for using the swagger-codegen-maven-plugin to generate the model DTOs. If you need more power and flexibility then use the Swagger Codegen Maven Plugin directly to generate the DTO and not this plugin.

The DTO classes may require additional dependencies such as:

    <dependency>
      <groupId>com.google.code.gson</groupId>
      <artifactId>gson</artifactId>
      <version>2.10.1</version>
    </dependency>
    <dependency>
      <groupId>io.swagger.core.v3</groupId>
      <artifactId>swagger-core</artifactId>
      <version>2.2.8</version>
    </dependency>
    <dependency>
      <groupId>org.threeten</groupId>
      <artifactId>threetenbp</artifactId>
      <version>1.6.8</version>
    </dependency>

The plugin supports the following additional options

The camel-restdsl-openapi:generate-xml goal of the Camel REST DSL OpenApi Maven Plugin is used to generate REST DSL XML implementation source code from Maven.

The plugin supports the following options which can be configured from the command line (use -D syntax), or defined in the pom.xml file in the <configuration> tag.

Works as generate-xml goal but also generates DTO model classes by automatic executing the swagger-codegen-maven-plugin to generate java source code of the DTO model classes from the OpenApi specification.

This plugin has been scoped and limited to only support a good effort set of defaults for using the swagger-codegen-maven-plugin to generate the model DTOs. If you need more power and flexibility then use the Swagger Codegen Maven Plugin directly to generate the DTO and not this plugin.

The DTO classes may require additional dependencies such as:

    <dependency>
      <groupId>com.google.code.gson</groupId>
      <artifactId>gson</artifactId>
      <version>2.10.1</version>
    </dependency>
    <dependency>
      <groupId>io.swagger.core.v3</groupId>
      <artifactId>swagger-core</artifactId>
      <version>2.2.8</version>
    </dependency>
    <dependency>
      <groupId>org.threeten</groupId>
      <artifactId>threetenbp</artifactId>
      <version>1.6.8</version>
    </dependency>

The plugin supports the following additional options

The camel-restdsl-openapi:generate-yaml goal of the Camel REST DSL OpenApi Maven Plugin is used to generate REST DSL YAML implementation source code from Maven.

The plugin supports the following options which can be configured from the command line (use -D syntax), or defined in the pom.xml file in the <configuration> tag.

Works as generate-yaml goal but also generates DTO model classes by automatic executing the swagger-codegen-maven-plugin to generate java source code of the DTO model classes from the OpenApi specification.

This plugin has been scoped and limited to only support a good effort set of defaults for using the swagger-codegen-maven-plugin to generate the model DTOs. If you need more power and flexibility then use the Swagger Codegen Maven Plugin directly to generate the DTO and not this plugin.

The DTO classes may require additional dependencies such as:

    <dependency>
      <groupId>com.google.code.gson</groupId>
      <artifactId>gson</artifactId>
      <version>2.10.1</version>
    </dependency>
    <dependency>
      <groupId>io.swagger.core.v3</groupId>
      <artifactId>swagger-core</artifactId>
      <version>2.2.8</version>
    </dependency>
    <dependency>
      <groupId>org.threeten</groupId>
      <artifactId>threetenbp</artifactId>
      <version>1.6.8</version>
    </dependency>

The plugin supports the following additional options

OpenShift Container Platform uses certain FIPS Validated / Modules in Process modules within RHEL and RHCOS for its operating system components. For example, when users SSH into OpenShift Container Platform clusters and containers, those connections are properly encrypted.

OpenShift Container Platform components are written in Go and built with Red Hat’s Golang compiler. When you enable FIPS mode for your cluster, all OpenShift Container Platform components that require cryptographic signing call RHEL and RHCOS cryptographic libraries.

For more details about FIPS, see FIPS mode attributes and limitations

For details on deploying Camel Spring Boot on OpenShift, see How to deploy a Camel Spring Boot application to OpenShift?

Details about supported configurations can be found at, Camel for Spring Boot Supported Configurations

All deprecated components from Camel 2.x are removed in Camel 3.x, including the old camel-http, camel-hdfs, camel-mina, camel-mongodb, camel-netty, camel-netty-http, camel-quartz, camel-restlet and camel-rx components.

Following components are renamed in Camel 3.x.

The mock component has been moved out of camel-core. Because of this a number of methods on its assertion clause builder are removed.

If you are using the activemq-camel component, then you should migrate to use camel-activemq component, where the component name has changed from org.apache.activemq.camel.component.ActiveMQComponent to org.apache.camel.component.activemq.ActiveMQComponent.

The component camel-aws has been split into multiple components:

The camel-cxf JAR has been divided into SOAP vs REST and Spring and non Spring JARs. It is recommended to choose the specific JAR from the following list when migrating from came-cxf.

For example, if you were using CXF for SOAP and with Spring XML, then select camel-cxf-spring-soap and camel-cxf-spring-transport when migrating from camel-cxf.

When using Spring Boot, choose from the following starter when you migrate from camel-cxf-starter to SOAP or REST:

The camel-cxf XML XSD schemas has also changed namespaces.

The camel-cxf SOAP component is moved to a new jaxws sub-package, that is, org.apache.camel.component.cxf is now org.apache.camel.component.cxf.jaws. For example, the CxfComponent class is now located in org.apache.camel.component.cxf.jaxws.

The camel-fhir component has upgraded it’s hapi-fhir dependency to 4.1.0. The default FHIR version has been changed to R4. Therefore if DSTU3 is desired it has to be explicitly set.

The camel-kafka component has removed the options bridgeEndpoint and circularTopicDetection as this is no longer needed as the component is acting as bridging would work on Camel 2.x. In other words camel-kafka will send messages to the topic from the endpoint uri. To override this use the KafkaConstants.OVERRIDE_TOPIC header with the new topic. See more details in the camel-kafka component documentation.

The camel-telegram component has moved the authorization token from uri-path to a query parameter instead, e.g. migrate

telegram:bots/myTokenHere

to

telegram:bots?authorizationToken=myTokenHere

If you run Camel standalone with just camel-core as a dependency, and you want JMX enabled out of the box, then you need to add camel-management as a dependency.

For using ManagedCamelContext you now need to get this extension from CamelContext as follows:

ManagedCamelContext managed = camelContext.getExtension(ManagedCamelContext.class);

The XSLT component has moved out of camel-core into camel-xslt and camel-xslt-saxon. The component is separated so camel-xslt is for using the JDK XSTL engine (Xalan), and camel-xslt-saxon is when you use Saxon. This means that you should use xslt and xslt-saxon as component name in your Camel endpoint URIs. If you are using XSLT aggregation strategy, then use org.apache.camel.component.xslt.saxon.XsltSaxonAggregationStrategy for Saxon support. And use org.apache.camel.component.xslt.saxon.XsltSaxonBuilder for Saxon support if using xslt builder. Also notice that allowStax is also only supported in camel-xslt-saxon as this is not supported by the JDK XSLT.

The XML DSL has been changed slightly.

The custom load balancer EIP has changed from <custom> to <customLoadBalancer>

The XMLSecurity data format has renamed the attribute keyOrTrustStoreParametersId to keyOrTrustStoreParametersRef in the <secureXML> tag.

The <zipFile> data format has been renamed to <zipfile>.