Apache Camel 4.x Upgrade Guide

This document is for helping you upgrade your Apache Camel application from Camel 4.x to 4.y. For example, if you are upgrading Camel 4.0 to 4.2, then you should follow the guides from both 4.0 to 4.1 and 4.1 to 4.2.

Upgrading Camel 4.11 to 4.12

camel-core

The package scan classes has moved from camel-base-engine to camel-support JAR and moved to a new package:

  • org.apache.camel.impl.engine.DefaultPackageScanClassResolver is moved to org.apache.camel.support.scan.DefaultPackageScanClassResolver

  • org.apache.camel.impl.engine.DefaultPackageScanResourceResolver is moved to org.apache.camel.support.scan.DefaultPackageScanResourceResolver

  • org.apache.camel.impl.engine.WebSpherePackageScanClassResolver is moved to org.apache.camel.support.scan.WebSpherePackageScanClassResolver

  • org.apache.camel.impl.scan.AnnotatedWithAnyPackageScanFilter is moved to org.apache.camel.support.scan.AnnotatedWithAnyPackageScanFilter

  • org.apache.camel.impl.scan.AnnotatedWithPackageScanFilter is moved to org.apache.camel.support.scan.AnnotatedWithPackageScanFilter

  • org.apache.camel.impl.scan.AssignableToPackageScanFilter is moved to org.apache.camel.support.scan.AssignableToPackageScanFilter

  • org.apache.camel.impl.scan.CompositePackageScanFilter is moved to org.apache.camel.support.scan.CompositePackageScanFilter

  • org.apache.camel.impl.scan.InvertingPackageScanFilter is moved to org.apache.camel.support.scan.InvertingPackageScanFilter

Type Converters

Using type converters that has been marked to allow null via (@Converter(allow-null = true)) has been improved to allow returning null as a positive answer when using convertBodyTo EIP and mandatoryConvertTo or getMandatoryBody etc.

This behaviour was present in Camel v2 and some internal optimization in Camel v3 had changed this to not be the case. Using type converters that can return null is a rare use-case, and it’s not a good practice.

Java DSL

When using Choice EIP then in some situations you may need to use .endChoice() to be able to either continue added more nodes to the current Choice EIP, or that you are working with nested Choice EIPs (choice inside choice), then you may also need to use endChoice to go back to the parent choice to continue from there.

However, there has been some regressions from upgrading older Camel releases to 4.11, and therefore we have refactored endChoice to work more consistent.

For example the following code

from("direct:start")
    .choice()
        .when(header("foo").isGreaterThan(1))
            .choice()
                .when(header("foo").isGreaterThan(5))
                    .to("mock:big")
                .otherwise()
                    .to("mock:med")
            .endChoice()
        .otherwise()
            .to("mock:low")
        .end();

Should now be

from("direct:start")
    .choice()
        .when(header("foo").isGreaterThan(1))
            .choice()
                .when(header("foo").isGreaterThan(5))
                    .to("mock:big")
                .otherwise()
                    .to("mock:med")
            .end().endChoice()
        .otherwise()
            .to("mock:low")
        .end();

Notice that the endChoice is changed to end().endChoice(). This is required to be consistent to end the current choice (inner) and then afterwards change the scope to be Choice EIP to be able to continue in the outer Choice. Otherwise the Java DSL cannot know the scope is Choice EIP and you would not be able to add the otherwise block to the outer Choice.

camel-as2

Add options allowing the addition of an Authorization header for Basic or Bearer authentication to client and asynchronous MDN requests.

Back to top