Chapter 1. Red Hat build of Apache Camel for Spring Boot 4.14 release notes

The camel-olingo4 component is now deprecated. This is due to the project Apache Olingo is no more maintained.

Red Hat build of Apache Camel for Spring Boot is upgraded to Spring Boot 3.5.x. For more information about the changes from Spring Boot 3.4 to Spring Boot 3.5, refer Spring Boot 3.5 Release notes.

Red Hat build of Camel Spring Boot is now supported on IBM Power and IBM Z.

The snowdrop groupId is changed from me.snowdrop to dev.snowdrop. You must update the pom.xml file accordingly.

To use the Automatic Camel context reloading on Secret Refresh feature, the secret update has to be done either via UI or via API call with opereation PutSecretValue. The camel context reload will not be triggered with executing updateSecret via Camel.

The following sections list the issues that have been resolved in Red Hat build of Apache Camel for Spring Boot 4.14.4.

In addition to above issues, Red Hat build of Apache Camel for Spring Boot version 4.14.4 also included several upstream fixes. For more information about these fixes, refer Resolved issues.

The following sections list the issues that have been resolved in Red Hat build of Apache Camel for Spring Boot 4.14.2 Patch 1.

The following sections list the issues that have been resolved in Red Hat build of Apache Camel for Spring Boot 4.14.2.

In addition to above issues, Red Hat build of Apache Camel for Spring Boot version 4.14 also included several upstream fixes. For more information about these fixes, refer Resolved issues.

The following sections list the issues that have been resolved in Red Hat build of Apache Camel for Spring Boot 4.14.

In addition to above issues, Red Hat build of Apache Camel for Spring Boot version 4.14 also included several upstream fixes. For more information about these fixes, refer Resolved issues.

When upgrading from version 4.10.3 to 4.10.7 of Red Hat build of Camel Spring Boot, the API changes in AgroalDataSourceAutoConfiguration require code updates, which specifically affect programmatic DataSource configurations. Projects that use programmatic DataSource definitions (rather than auto-configuration) will experience compilation errors and need code modifications. After upgrading from version 4.10.3 to 4.10.7, the AgroalDataSourceAutoConfiguration constructor requires additional parameters wrapped in ObjectProvider.

Following sample shows the required changes.

    @ConfigurationProperties("app.datasource.ds1.agroal")
    public AgroalDataSource firstDataSource(
        @Qualifier("ds1properties") DataSourceProperties properties,
        JtaTransactionManager jtaPlatform,
        XAResourceRecoveryRegistry xaResourceRecoveryRegistry,
        ObjectProvider<AgroalDataSourceJndiBinder> jndiBinder) {

        return new AgroalDataSourceAutoConfiguration(jtaPlatform, xaResourceRecoveryRegistry)
            .dataSource(properties, false, false, jndiBinder);
    }

    @ConfigurationProperties("app.datasource.ds1.agroal")
    public AgroalDataSource firstDataSource(
        @Qualifier("ds1properties") DataSourceProperties properties,
        ObjectProvider<JtaTransactionManager> jtaPlatform,
        ObjectProvider<XAResourceRecoveryRegistry> xaResourceRecoveryRegistry,
        ObjectProvider<AgroalDataSourceJndiBinder> jndiBinder,
        ObjectProvider<AgroalSecurityProvider> securityProvider) {

        return new AgroalDataSourceAutoConfiguration(jtaPlatform, xaResourceRecoveryRegistry, jndiBinder, securityProvider)
            .dataSource(properties, true, false, false, new ArrayList<Object>(), new ArrayList<Object>());
    }

However, the /actuator/health wil be not exposed without the configuration of the actuator. This creates discordance between the readiness/liveness probes configured by JKube (they both uses the above endpoint) and what the application is exposing.

This misconfiguration causes a failing deployment config on OpenShift Container Platform since the generated pod will never be in Ready status since the probe`s call for an endpoint is not configured. So in order to make the application work on OpenShift Container Platform, which is deployed using JKube (openshift-maven-plugin), it is necessary to have both web and actuator autoconfiguration in the dependencies.

Following example shows how to configure web and actuator autoconfiguration.

<dependency>
 <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

Update the archetype as shown below. The applications built from the following archetype will be deployed correctly using JKube.

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-web</artifactId>
    <exclusions>
      <exclusion>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-tomcat</artifactId>
      </exclusion>
    </exclusions>
</dependency>
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-undertow</artifactId>
</dependency>
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

This issue affects the custom applications with missing one of the above dependencies.