1.8. 已知问题
查看以下已知问题,深入了解红帽构建的 Quarkus 3.8 限制和临时解决方案。
1.8.1. Infinispan 客户端扩展无法在 FIPS 和原生 Mandrel 23.1 上工作 复制链接链接已复制到粘贴板!
在原生模式下,当使用来自 registry.redhat.io/quarkus/mandrel-for-jdk-21-rhel8 的红帽构建的 Quarkus Infinispan 客户端扩展程序容器时,红帽构建的 Quarkus Infinispan 客户端扩展不适用于启用了联邦信息处理标准(FIPS)的系统。
临时解决方案:避免将原生模式用于这个原生镜像构建器。目前还没有可用的临时解决方案。
1.8.2. Strimzi OAuth 客户端更新到 0.14.0 的原生构建失败 复制链接链接已复制到粘贴板!
因为将 io.strimzi:strimzi-kafka-oauth 依赖项更新到 0.14.0,导致 Strimzi OAuth 客户端遇到一个已知问题,从而导致 没有加载 io.smallrye.reactive.kafka.graal.Target_com_jayway_jsonpath_DefaultsImpl 指示的原生构建失败。
临时解决方案: 要解决这个问题,请在 classpath 中包含 io.strimzi:kafka-oauth-common 依赖项。
1.8.3. 在 AArch64 上缺少 Kafka Streams 扩展的原生库 复制链接链接已复制到粘贴板!
由于没有原生库 librocksdbjni-linux-AArch64.so,使用 quarkus-kafka-streams 扩展的应用程序在 AArch64 系统上具有运行时失败。这个问题会抛出 java.lang.RuntimeException: librocksdbjni-linux-AArch64.so,在应用程序启动过程中没有找到 JAR 错误。此错误可防止成功初始化 RocksDB 组件,这对 Kafka Streams 应用程序至关重要。
临时解决方案:目前还没有可用的临时解决方案。
java.lang.RuntimeException 示例: librocksdbjni-linux-AArch64.so 错误
1.8.4. Microsoft Windows 上 Kafka Streams 扩展缺少原生库 复制链接链接已复制到粘贴板!
在 Microsoft Windows 上使用 quarkus-kafka-streams 扩展的应用程序会因为没有原生库 librocksdbjni-win64.dll 而有运行时失败。这个问题会在应用程序启动过程中 没有找到 java.lang.RuntimeException: librocksdbjni-win64.dll in JAR 错误。
此错误可防止成功初始化 RocksDB 组件,这对 Kafka Streams 应用程序至关重要。
临时解决方案:目前还没有可用的临时解决方案。
java.lang.RuntimeException: librocksdbjni-win64.dll 错误
1.8.5. 明确说明原生构建期间缺少 Vert.x 类 复制链接链接已复制到粘贴板!
在原生构建期间,开发人员可能会获取 Vert.x 类的 java.lang.ClassNotFoundException 错误,如 io.vertx.core.http.impl.Http1xServerResponse 和 io.vertx.core.parsetools.impl.RecordParserImpl。这些错误在构建应用程序时发生,包括使用 quarkus-qpid-jms 扩展的应用程序,而无需包括 Vert.x 作为直接或传输的依赖项。
阐明 quarkus-qpid-jms 不直接使用 Vert.x 非常重要。这个问题来自 quarkus-netty 扩展,quarkus-qpid-jms 使用它。quarkus-netty 扩展负责在原生构建期间为运行时初始化注册这些 Vert.x 类,而无需验证其存在。当构建中没有引入 Vert.x 的扩展时,这会导致注意的例外。
这些 ClassNotFoundException 错误会在构建过程中记录,但不影响应用程序的功能。它们是原生构建过程的结果,以及依赖项在红帽构建的 Quarkus 中处理的方式,特别是通过 quarkus-netty 模块。
java.lang.ClassNotFoundException 错误示例
临时解决方案:要防止这些日志条目并确保正确识别所有依赖项,您可以选择将 quarkus-vertx 扩展添加到项目中。
1.8.6. 在 OpenShift 上测试 JVM 模式中的 AArch64 支持限制 复制链接链接已复制到粘贴板!
从 Red Hat build of Quarkus 3.2 开始,在带有 AArch64 的 Red Hat OpenShift Container Platform 上进行 JVM 的测试管道会有一些已知的限制:
- AArch64 不支持 Red Hat Serverless。在 AArch64 架构上运行的 OpenShift 集群上支持 Red Hat Serverless 的功能请求在 SRVCOM-2472 中进行跟踪,计划在 Serverless 1.33 中包含支持。
- AArch64 不支持 Red Hat AMQ Streams。因为 AArch64 上还不支持 AMQ Streams,所以此集成的支持还没有被测试。这个问题目前没有在红帽问题管理系统中跟踪。
- AArch64 不支持 Red Hat Single Sign-On。因为 Red Hat Single Sign-On 和 Red Hat build of Keycloak 尚不在 AArch64 上被支持,所以与 Red Hat build of Quarkus 应用程序的集成还没有被测试。
- AArch64 不支持服务绑定。因为 AArch64 还不支持与 Red Hat build of Quarkus 进行服务绑定集成的绑定服务,所以还没有测试此集成。另外,OpenShift Service Binding Operator 在 OpenShift Container Platform (OCP) 4.13 及更高版本中已弃用,计划在以后的 OCP 发行版本中删除。
AArch64 支持仅限于 Red Hat Universal Base Image (UBI)容器,且不会扩展到裸机环境。
临时解决方案:目前还没有可用的临时解决方案。
1.8.7. 对 org.apache.maven:maven:pom:3.6.3 的依赖项可能会导致代理问题 复制链接链接已复制到粘贴板!
在使用某些 Quarkus 扩展时,可能会解决对 org.apache.maven:maven:pom:3.6.3 的依赖。这不适用于 Gradle 插件,但会影响到任何具有 io.smallrye:smallrye-parent:pom:37 的项目,在其父项目对象模型(POM)层次结构中。对于代理后面的环境,这个依赖关系可能会导致构建失败,以限制对版本 3.6.x 的 org.apache.maven 工件的访问。Maven 3.6.3 中的二进制软件包都作为 Quarkus 核心框架或支持的 Quarkus 扩展的依赖项下载。
临时解决方案:目前还没有可用的临时解决方案。
如需更多信息,请参阅 QUARKUS-1025 - Gradle 插件在 maven core 3.6.x 中拖动。
红帽构建的 Quarkus 3.8 提供了更高的稳定性,包括对用户有严重影响的错误的修复。
要获得红帽构建的 Quarkus 的最新修复,请确保您使用最新的可用版本,即 3.8.6.SP3-redhat-00002。