Red Hat Summit이 콘텐츠는 선택한 언어로 제공되지 않습니다.
Chapter 1. Release notes for Red Hat build of Apache Camel for Quarkus 3.8 / 3.8.6.SP2
1.1. Red Hat build of Apache Camel for Quarkus features
- Fast startup and low RSS memory
- Using the optimized build-time and ahead-of-time (AOT) compilation features of Quarkus, your Camel application can be pre-configured at build time resulting in fast startup times.
- Application generator
- Use the Quarkus application generator to bootstrap your application and discover its extension ecosystem.
- Highly configurable
All the important aspects of a Red Hat build of Apache Camel for Quarkus application can be set up programmatically with CDI (Contexts and Dependency Injection) or by using configuration properties. By default, a CamelContext is configured and automatically started for you.
Check out the Configuring your Quarkus applications by using a properties file guide for more information on the different ways to bootstrap and configure an application.
- Integrates with existing Quarkus extensions
- Red Hat build of Apache Camel for Quarkus provides extensions for libraries and frameworks that are used by some Camel components which inherit native support and configuration options.
1.2. Supported platforms, configurations, databases, and extensions
- For information about supported platforms, configurations, and databases in Red Hat build of Apache Camel 4.4 for Quarkus 3 GA, see the Supported Configuration page on the Customer Portal (login required).
- For a list of Red Hat Red Hat build of Apache Camel for Quarkus extensions and the Red Hat support level for each extension, see the Extensions Overview chapter of the Red Hat build of Apache Camel for Quarkus Reference (login required).
1.3. BOM files for Red Hat build of Apache Camel for Quarkus
-
To configure your Red Hat Red Hat build of Apache Camel for Quarkus version 3.8 projects to use the supported extensions, use the latest Bill Of Materials (BOM) version
3.8.6.SP2-redhat-00002or newer, from the Redhat Maven Repository.
For more information about BOM dependency management, see Developing Applications with Red Hat build of Apache Camel for Quarkus
1.4. Technology preview extensions
Items designated as Technology Preview in the Extensions Overview chapter of the Red Hat build of Apache Camel for Quarkus Reference have limited supportability, as defined by the Technology Preview Features Support Scope.
1.5. Product errata and security advisories
1.5.1. Red Hat build of Apache Camel for Quarkus
For the latest Red Hat build of Apache Camel for Quarkus product errata and security advisories, see the Red Hat Product Errata page.
1.5.2. Red Hat build of Quarkus
For the latest Red Hat build of Quarkus product errata and security advisories, see the Red Hat Product Errata page.
1.6. Known issues
1.6.1. NoClassDefFoundError when compiling native project
Compiling a native project can result in a NoClassDefFoundError like this:
The reason is that netty-codec-socks is excluded in the quarkus-qpid-jms extension, which camel-quarkus-amqp depends on.
- Workaround
-
You can avoid the errror by manually adding the
netty-codec-socksdepencency.
1.6.2. Issues with Quarkus on AArch64 systems
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:
1.6.3. Websocket + Knative does not work with HTTP2
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.
1.6.4. Other known issues
- Quarkus native compilation of camel-quarkus-jackson-avro fails
If you try to compile a Camel Quarkus application that uses the
camel-quarkus-jackson-avroextension to native code, the compilation fails with anUnsupportedFeatureExceptionerror.As a workaround, you can build the application with
camel-quarkus-jackson-avroextension using the parameter-Dquarkus.native.additional-build-args=--initialize-at-run-time=org.apache.avro.file.DataFileWriteror add that configuration property to yoursrc/main/resources/application.propertiesfile.For more information, see the support article "Quarkus native compilation of camel-quarkus-jackson-avro fails" in the customer portal. (Login required)
- Moving from
smallrye-metricstocamel-quarkus-micrometerrequires manual registration of beans If you are migrating to
micrometerfromsmallrye-metrics, you may need to manually define some beans as scoped.In
smallrye-metrics, classes that are registered for metrics (for example with@COUNTED,@METRIC), but not registered as scoped beans, are registered automatically. This does not happen inmicrometer.In
micrometeryou need to manually register beans accessed via CDI, by for example adding a@Dependentannotation.
- Camel-quarkus-snmp not supported in Native
-
In Red Hat build of Apache Camel for Quarkus we support the
camel-quarkus-snmpcomponent in JVM mode only.
1.7. Known Quarkus CXF issues
CXF is fully supported, but the following issues remain with this release of Red Hat build of Apache Camel for Quarkus.
1.7.1. Name clash between Service methods with the same name in one Java package
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.
1.8. Beans not injected into a service implementation with @CXFEndpoint("/my-path")
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:
Example
quarkus.cxf.endpoint."/myPath".implementor = org.acme.MyServiceImpl
quarkus.cxf.endpoint."/myPath".implementor = org.acme.MyServiceImpl1.9. Important notes
1.9.1. The javax to jakarta Package Namespace Change
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.
This change does not affect javax packages that are part of Java SE.
When migrating applications to EE 10, you need to:
-
Update any import statements or other source code uses of EE API classes from the
javaxpackage tojakarta. -
Change any EE-specified system properties or other configuration properties whose names begin with
javax.to begin withjakarta.. -
Use the
META-INF/services/jakarta.[rest_of_name]name format to identify implementation classes in your applications that use the implement EE interfaces or abstract classes bootstrapped with thejava.util.ServiceLoadermechanism.
1.9.1.1. Migration tools
- Source code migration: How to use Red Hat Migration Toolkit for Auto-Migration of an Application to the Jakarta EE 10 Namespace
- Bytecode transforms: For cases where source code migration is not an option, the open source Eclipse Transformer
Additional resources
- Background: Update on Jakarta EE Rights to Java Trademarks
- Red Hat Customer Portal: Red Hat JBoss EAP Application Migration from Jakarta EE 8 to EE 10
- Jakarta EE: Javax to Jakarta Namespace Ecosystem Progress
1.9.2. Support for IBM Power and IBM Z
Red Hat build of Apache Camel for Quarkus is now supported on IBM Power and IBM Z.
1.9.3. Minimum Java version - JDK 17
Red Hat build of Apache Camel for Quarkus version 3.8 requires JDK 17 or newer.
1.9.4. Support for OpenJDK
Red Hat build of Apache Camel for Quarkus version 3.8 includes support for OpenJDK 21.
1.9.5. Support for AdoptiumJDK
Red Hat build of Apache Camel for Quarkus version 3.8 includes support for AdoptiumJDK 17 and AdoptiumJDK 21.
1.10. Upgrades
1.10.1. Camel upgraded from version 4.0 to version 4.4
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:
1.10.2. Camel Quarkus upgraded from version 3.2 to version 3.8
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:
- Apache Camel Quarkus 3.2.1 Release Notes
- Apache Camel Quarkus 3.2.2 Release Notes
- Apache Camel Quarkus 3.2.3 Release Notes
- Apache Camel Quarkus 3.4.0 Release Notes
- Apache Camel Quarkus 3.5.0 Release Notes
- Apache Camel Quarkus 3.6.0 Release Notes
- Apache Camel Quarkus 3.7.0 Release Notes
- Apache Camel Quarkus 3.8.0 Release Notes
1.11. Resolved issues
The following lists shows known issues that were affecting Red Hat build of Apache Camel for Quarkus, which have been fixed in Red Hat build of Apache Camel for Quarkus version 3.8.
1.11.1. Resolved issues in Quarkus CXF 3.8.6
Before Quarkus CXF 3.8.6, the values specified in quarkus.cxf.codegen.wsdl2java.package-names
quarkus.cxf.codegen.wsdl2java.package-names were wrongly passed as a single comma-separated value of the -p option, leading to BadUsageException: -p has invalid character!.
Since Quarkus CXF 3.8.6, if quarkus.cxf.codegen.wsdl2java.package-names specifies multiple mappings, such as
application.properties
quarkus.cxf.codegen.wsdl2java.package-names = http://www.example.org/add=io.quarkiverse.cxf.wsdl2java.it.add, http://www.example.org/multiply=io.quarkiverse.cxf.wsdl2java.it.multiply
quarkus.cxf.codegen.wsdl2java.package-names =
http://www.example.org/add=io.quarkiverse.cxf.wsdl2java.it.add,
http://www.example.org/multiply=io.quarkiverse.cxf.wsdl2java.it.multiply
then they are properly passed to wsdl2java as multiple -p options:
wsdl2java \ -p http://www.example.org/add=io.quarkiverse.cxf.wsdl2java.it.add \ -p http://www.example.org/multiply=io.quarkiverse.cxf.wsdl2java.it.multiply \ ...
wsdl2java \
-p http://www.example.org/add=io.quarkiverse.cxf.wsdl2java.it.add \
-p http://www.example.org/multiply=io.quarkiverse.cxf.wsdl2java.it.multiply \
...1.11.1.2. Beans not injected into a service implementation with @CXFEndpoint("/my-path")
When backporting fixes from the main branch of Quarkus CXF to 3.8, we mistakenly ported a new feature allowing to specify CXF service endpoint paths through the new annotation @CXFEndpoint("/myPath").
The new code did 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 ere left blank and the service call throws a NullPointerException.
Service implementations not using the new @CXFEndpoint annotations are unaffected.
The code introducing the new @CXFEndpoint("/myPath") functionality was removed in this release.
We recommend that you continue to specify service endpoint paths in application.properties, for example:
Example
quarkus.cxf.endpoint."/myPath".implementor = org.acme.MyServiceImpl
quarkus.cxf.endpoint."/myPath".implementor = org.acme.MyServiceImpl1.11.2. Resolved issues in Red Hat build of Apache Camel for Quarkus 4.4
- CEQ-8857
- Camel-http producer sets "Content-Encoding=UTF-8"
1.11.3. Previous releases
For details of issues resolved between Camel Quarkus 3.2 and Camel Quarkus 3.8, see the Release Notes for each patch release.
1.12. Deprecated features in Red Hat build of Apache Camel for Quarkus version 3.8
The following capabilities are not available in the next major release of Red Hat build of Apache Camel for Quarkus, and are deprecated in this release.
1.12.1. Openapi-java support for Openapi v2
Deprecated features
OpenApi V2 is deprecated in 3.8, due to dropped support in Openapi-java with Camel 4.5.x.
1.13. Extensions removed in Red Hat build of Apache Camel for Quarkus version 3.8
No extensions are removed in the Red Hat build of Apache Camel for Quarkus version 3.8 release.
1.14. Extensions added in Red Hat build of Apache Camel for Quarkus version 3.8
The following table lists the extensions added in the Red Hat build of Apache Camel for Quarkus version 3.8 release .
| Extension | Artifact | Description |
|---|---|---|
| Jasypt |
| Security using Jasypt |
| JSON Path |
| Evaluate a JSONPath expression against a JSON message body |
| JT400 |
| Exchanges messages with an IBM i system using data queues, message queues, or program call. IBM i is the replacement for AS/400 and iSeries servers. |
| Kudu |
| Interact with Apache Kudu, a free and open source column-oriented data store of the Apache Hadoop ecosystem. |
| LRA |
| Camel saga binding for Long-Running-Action framework. |
| Saga |
| Execute custom actions within a route using the Saga EIP. |
| Splunk HEC |
| The splunk component allows to publish events in Splunk using the HTTP Event Collector. |
| XJ |
| Transform JSON and XML message using a XSLT. |
No extensions have changed support levels in the Red Hat build of Apache Camel for Quarkus version 3.8 release.
For information about support levels, see Red Hat build of Apache Camel for Quarkus Extensions
1.16. Data formats added in Red Hat build of Apache Camel for Quarkus version 3.8
No data formats have been added in the Red Hat build of Apache Camel for Quarkus version 3.8 release..
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}