Search
SupportConsoleDevelopersStart a trialContact

Chapter 7. Camel Migration Issues

download PDF

7.1. Camel 2.21 Migration Issues

Fuse 7.0 uses Camel 2.21. This section covers the changes in Camel 2.21 that are to be considered before upgrading to Fuse 7.0.

The changes to Camel 2.21 that must be considered before upgrading:

  • Jetty has been upgraded to version 9.4 by default and camel-jetty needs version 9.3 or 9.4 to run in OSGi.
  • The component camel-saxon is used to create the SaxonXpathFactory class is from Saxon. In absence of camel-saxon the factory method is created as per the old way.
  • The camel-json-validator component uses the NetworkNT JSon Schema validator library instead of Everit. Everit had ASF license implications and will be removed from future Camel releases. The NetworkNT supports v4 draft of JSon Schema for validation so update your schemas to use the draft version.
  • The FileIdempotentRepository is updated to use the internal in-memory cache for quick lookup of the most frequent file names, and for lookup from disk. See the class javadoc of the file for more details.
  • The Karaf commands for routes are changed so the arguments for the camel context is placed first, and the route id is the second argument. This allows the route completer to use the selected camel context name to only show route ids from that camel context else it shows all the routes for every Camel application running in Karaf.
  • The camel-spring-boot actuator endpoints for routes are now in read-only mode by default. The operations to start, stop, suspend, `resume routes is forbidden. You can turn off read-only mode by setting the spring boot configuration endpoints.camelroutes.read-only = false.

7.2. Camel 2.20 Migration Issues

This section covers the changes in Camel 2.20 that are to be considered before upgrading to Fuse 7.0.

The changes to Camel 2.20 that must be considered before upgrading:

  • The Maven version 3.3.3 or higher is required to build the project.
  • The camel-dropbox is upgraded to v2 api. There can be backward compatibility issues becuase of the V2 upgrade.
  • In the camel-infinispan the result is not set in the CamelInfinispanOperationResult header but in the in body. To change this behavior you can set the header CamelInfinispanOperationResultHeader with the name of the header that contains the result or with the resultHeader URI option.
  • The camel-infinispan URI option command has been deprecated and replaced by operation for consistency purposes.
  • In camel-infinispan commands are changed to use the short form such as PUT, GET. The old operation names CamelInfinispanOperationPut and CamelInfinispanOperationGet have been deprecated.
  • In camel-undertow the matchOnUriPrefix option, the default value is set to FALSE to make it consistent with other components such as, Camel HTTP components.
  • The Twitter components are split into four types, directmessage, search, streaming and timeline and has its own endpoint and scheme.
  • The RuntimeEndpointRegistry is no longer in extended mode by default. To use extended mode, set the management statistics level to Extended explicitly.
  • There is no RuntimeEndpointRegistry in use by default. You need to explicitly configure a registry to be used, or turn it on using the management agent, or set the statistics level to extended mode.
  • Camel with Spring XML routes do not register endpoints in the Spring registry from Camel routes where <from> or <to> have endpoints assigned with an explicit id attribute. The option registerEndpointIdsFromRoute can be set to true on <camelContext> for backward compatibility. But this registration is deprecated and instead you should use <endpoint> to register Camel endpoints with id’s in Spring registry.
  • The camel-spring-dm has been removed. For XML DSL with OSGi use camel-blueprint.
  • Copying streams in IOHelper from came-core now regard EOL of data if the first read byte is zero. This change is a work around for issues on application servers such as IBM WebSphere. The setting can be turned off by configuring JVM system property "camel.zeroByteEOLEnabled=false".
  • The camel-jms component is based on the JMS 2.0 API (geronimo-jms_2.0_spec) instead of JMS 1.1 API (geronimo-jms_1.1_spec). But camel-jms works at runtime with both JMS 1.1 or 2.0.
  • The camel-kura is upgraded to newer OSGi API version.
  • The camel-stomp uses the destination without replacing all slash characters with colon.
  • The camel-ignite is updated to use Ignite version 2.2.x .
  • The camel-dozer has been upgraded from Dozer v5 to v6 which requires migration. See, Dozer migration guides https://dozermapper.github.io/gitbook/migration/v5-to-v6.html and https://dozermapper.github.io/gitbook/migration/v6-to-v61.html

7.3. Camel 2.19 Migration Issues

There are a number of changes in Camel 2.19 that have to be considered before upgrading to Fuse 7.0.

There are known issues that can break the API.

  • The groovy DSL from camel-groovy has been moved to camel-groovy-dsl module. The camel-groovy contains only the Camel Groovy Language.
  • The Camel-spring-LDAP uses java.util.function.BiFunction<L, Q, S> instead of org.apache.camel.component.springldap.LdapOperationsFunction<Q, S>.
  • The deprecated APIs from camel-spring-boot has been removed to upgrade and support Spring Boot 1.5.x .
  • The camel-mongodb-gridf schema is renamed to mongodb-gridfs.
  • The commands-core Catalog commands have been removed.
  • The org.apache.camel.spring.boot.FatJarRouter is removed so you use the regular RouteBuilder classes in Spring Boot applications.
  • The Kafka endpoint option seekToBeginning=true should be migrated to seekTo=beginning.
  • The Kafka endpoint option bridgeEndpoint has moved from endpoint to the KafkaConfiguration class.
  • The Kafka component is now easier to configure and use. There is a backwards incompatible change so users need to migrate. The kafka URI is changed from kafka:brokers to kafka:topic. So you need to specify the topic name in the context-path and the brokers as parameters, for example, the old syntax was kafka:myserver?topic=sometopic which is changed to kafka:sometopic?brokers=myserver.
  • The Infinispan URI syntax has changed from infinispan:hostName?options to infinispan:cacheName?options.

There are changes to Camel 2.19 that must be considered before upgrading:

  • The camel-spring-dm has been disabled from the Karaf features file so users cannot install it out of the box, it is also deprecated and users are encouraged to use OSGi Blueprint instead. The JAR is still shipped and can be installed manually but it there is no support avaiable. The JAR will be removed completed in a future release.
  • The Groovy DSL and Scala DSL is deprecated and will be moved to Camel Extra and not distributed out of the box in the future.
  • Camel now uses Karaf 4.x API and therefore not possible to run on older Karaf versions.
  • The camel-blueprint changed startup behavior to start on Blueprint.CREATED event which is more appropriate way of startup instead of Blueprint.REGISTERED as was used previously.
  • The camel-spring-boot does not include prototype scoped beans when auto scanning for RouteBuilder instances, which is how camel-spring works. You can revert back using the includeNonSingletons option.
  • The camel-spring-javaconfig removed from Karaf features as it was not supported in OSGi/Karaf.
  • The camel spring-boot shell commands have been removed as spring-boot shell has been deprecated in spring-boot.
  • The camel-box has been migrated to use box v2 api so there may be some migration needed as the old camel-box component was using box v1 api.
  • The JSon schema from camel-catalog have changed to use boolean, integer and numeric values when applicable instead of using string values.
  • The camel-catalog Karaf commands has been removed.
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.