Chapter 1. Release notes for Red Hat build of Apache Camel for Quarkus 3.8 / 3.8.4.SP2

There currently are problems and limitations with Quarkus 3.8 on AArch64 systems. For more information, see the release notes for Red Hat build of Quarkus 3.8:

We support both camel-quarkus-grpc and camel-vertx-websocket with Knative.

gRPC needs HTTP2 (you can find instructions on how to enable it here: HTTP2 on Knative).

Unfortunately, Websockets with Knative does not work with HTTP2 (see Ingress Operator in OpenShift Container Platform).

Consequently, if you have an application that is intended to accept WebSocket connections, it must not allow negotiating the HTTP/2 protocol or else clients will fail to upgrade to the WebSocket protocol.

SmallRye Config supports implementing custom secret key expressions of the form ${handler::value}, where the handler is the name of a io.smallrye.config.SecretKeysHandler to decode or decrypt the value separated by a double colon ::.

If the SecretKeysHandler is implemented in the user application, then, if the wsdl2Java code generation is enabled, it fails with an error message like the following:

Failed to execute goal io.quarkus.platform:quarkus-maven-plugin:3.8.0:generate-code (default) on project fallgruppenbestimmung: Quarkus code generation phase has failed: InvocationTargetException: io.smallrye.config.SecretKeysHandler: Provider org.acme.MySecretKeyHandler not found

If there are two SEIs in one Java package, both having a @WebMethod with the same name but different signature, then the default name for the generated request, response and possibly other classes is the same for both methods of both classes.

As of Quarkus CXF 3.8.3, no exception is thrown when this happens during the class generation at build time. At runtime, only one set of those classes is present and therefore calls to one of the clients fail inevitably.

The @CXFEndpoint annotation was mistakenly introduced in Red Hat build of Apache Camel for Quarkus 3.8.4.SP2 and Quarkus CXF 3.8.4. It is reverted in the of Red Hat build of Apache Camel for Quarkus 3.8 and Quarkus CXF 3.8.5.

The annotation allows you to specify CXF service endpoint paths through the new annotation @CXFEndpoint("/myPath").

This does not work well for service implementation classes having both @WebService and @CXFEndpoint annotations. In those cases, if the service has some @Inject fields, those fields are left blank and the service call throws a NullPointerException.

Service implementations that do not have the @CXFEndpoint annotations are unaffected.

We recommend that you continue to specify service endpoint paths in application.properties as before:

quarkus.cxf.endpoint."/myPath".implementor = org.acme.MyServiceImpl

The Java EE move to the Eclipse Foundation and the establishment of Jakarta EE, since Jakarta EE 9, packages used for all EE APIs have changed to jakarta.*

Code snippets in documentation have been updated to use the jakarta.* namespace, but you of course need to take care and review your own applications.

When migrating applications to EE 10, you need to:

Red Hat build of Apache Camel for Quarkus is now supported on IBM Power and IBM Z.

Red Hat build of Apache Camel for Quarkus version 3.8 requires JDK 17 or newer.

Red Hat build of Apache Camel for Quarkus version 3.8 includes support for OpenJDK 21.

Red Hat build of Apache Camel for Quarkus version 3.8 includes support for AdoptiumJDK 17 and AdoptiumJDK 21.

Red Hat build of Apache Camel for Quarkus version 3.8 has been upgraded from Camel version 4.0 to Camel version 4.4. For additional information about each intervening Camel patch release, refer to the following:

Red Hat build of Apache Camel for Quarkus version 3.8 has been upgraded from Camel Quarkus version 3.2 to Camel Quarkus version 3.8. For additional information about each intervening Camel Quarkus patch release, refer to the following:

For details of issues resolved between Camel Quarkus 3.2 and Camel Quarkus 3.8, see the Release Notes for each patch release.