Chapter 1. Release notes for Red Hat build of Quarkus 3.15 Release notes provide information about new features, notable technical changes, features in technology preview, bug fixes, known issues, and related advisories for Red Hat build of Quarkus 3.15. These include the following notable changes: Simplified and unified TLS configuration JDK Flight Recorder extension (introduced as a Technology Preview) Generation of reflection-free Jackson serializers (introduced as a Technology Preview) Infinispan cache extension introduced (introduced as a Technology Preview) container-image-podman extension introduced Information about upgrading and backward compatibility is also provided to help you make the transition from an earlier release. 1.1. About Red Hat build of Quarkus Red Hat build of Quarkus is a Kubernetes-native Java stack optimized for containers and Red Hat OpenShift Container Platform. Quarkus is designed to work with popular Java standards, frameworks, and libraries such as Eclipse MicroProfile, Eclipse Vert.x, Apache Camel, Apache Kafka, Hibernate ORM with Jakarta Persistence, and Jakarta REST. As a developer, you can choose the Java frameworks you want for your Java applications, which you can run in Java Virtual Machine (JVM) mode or compile and run in native mode. Quarkus provides a container-first approach to building Java applications. The container-first approach facilitates the containerization and efficient execution of microservices and functions. For this reason, Quarkus applications have a smaller memory footprint and faster startup times. Quarkus also optimizes the application development process with capabilities such as unified configuration, automatic provisioning of unconfigured services, live coding, and continuous testing that gives you instant feedback on your code changes. 1.2. Differences between the Quarkus community version and Red Hat build of Quarkus As an application developer, you can access two different versions of Quarkus: the Quarkus community version and the productized version, Red Hat build of Quarkus. The following table describes the differences between the Quarkus community version and Red Hat build of Quarkus. Feature Quarkus community version Red Hat build of Quarkus version Description Access to the latest community features Yes No With the Quarkus community version, you can access the latest feature developments. Red Hat does not release Red Hat build of Quarkus to correspond with every version that the community releases. The cadence of Red Hat build of Quarkus feature releases is approximately every six months. Enterprise support from Red Hat No Yes Red Hat provides enterprise support for Red Hat build of Quarkus only. To report issues about the Quarkus community version, see quarkusio/quarkus - Issues . Access to long-term support No Yes The lifecycle for a major release of Red Hat build of Quarkus is divided into two support phases; full support and maintenance support. For information about the product lifecycle, timelines, and support policies of Red Hat build of Quarkus, log in to the Red Hat Customer Portal and see the Product lifecycles and Red Hat build of Quarkus lifecycle and support policies Knowledge Base articles. Common Vulnerabilities and Exposures (CVE) fixes and bug fixes backported to earlier releases No Yes With Red Hat build of Quarkus, selected CVE fixes and bug fixes are regularly backported to supported streams. For more information about maintenance support, see Red Hat build of Quarkus lifecycle and support policies . Tested and verified with Red Hat OpenShift Container Platform and Red Hat Enterprise Linux (RHEL) No Yes Red Hat build of Quarkus is built, tested, and verified with Red Hat OpenShift Container Platform and RHEL. Red Hat provides both production and development support for supported configurations and tested integrations according to your subscription agreement. For more information, see Red Hat build of Quarkus supported configurations . Built from source using secure build systems No Yes In Red Hat build of Quarkus, the core platform and all supported extensions are provided by Red Hat using secure software delivery, which means that they are built from source, scanned for security issues, and with verified license usage. Access to support for JDK and Red Hat build of Quarkus Native builder distribution No Yes Red Hat build of Quarkus supports certified OpenJDK builds and certified native executable builders. See admonition below. For more information, see Red Hat build of Quarkus supported configurations . Important To build native Linux executables , Red Hat build of Quarkus supports using the Red Hat build of Quarkus Native Builder image (quarkus/mandrel-for-jdk-21-rhel8) , which is based on GraalVM Mandrel . Red Hat build of Quarkus does not support building native executables by using Oracle GraalVM Community Edition (CE), Mandrel community edition, or any other GraalVM distributions. For more information, see Compiling your Red Hat build of Quarkus applications to native executables . 1.3. New features, enhancements, and technical changes This section overviews the new features, enhancements, and technical changes introduced in Red Hat build of Quarkus 3.15. 1.3.1. Compatibility 1.3.1.1. Spring API refactored to align with Spring Boot 3 With Red Hat build of Quarkus 3.15, the quarkus-spring-data-rest-extension is refactored to align with the latest spring-data-jpa 3.x updates. This update introduces the following key changes: Two new interfaces, ListCrudRepository and ListPagingAndSortingRepository . These new List methods are not exposed by Quarkus REST, consistent with Spring's behavior. Modifications to the class hierarchy: PagingAndSortingRepository no longer extends CrudRepository ListCrudRepository extends CrudRepository ListPagingAndSortingRepository extends PagingAndSortingRepository JpaRepository extends both ListCrudRepository and ListPagingAndSortingRepository This refactoring introduces breaking changes. For more information, see the Changes that affect compatibility with earlier versions chapter. 1.3.2. Core 1.3.2.1. container-image-podman extension introduced Red Hat build of Quarkus 3.15 introduces a new extension, container-image-podman , dedicated to Podman. If you prefer Podman over Docker, you can now use this new extension. It replicates the functionality of the existing container-image-docker extension while offering support for building container images with Podman and loading them into a local registry. Although the container-image-docker extension is and has always been compatible with Podman's Docker-compatible API, container-image-podman is tailored for building images seamlessly with the Podman toolset. Use the container-image-docker extension for Docker-specific tasks and the container-image-podman extension for tasks related to Podman. For example, building multi-platform images is implemented differently for Docker and Podman. Docker uses the Buildx plugin, whereas Podman can build multi-platform images natively. Because of this, you must use the specific extension to perform that function. 1.3.2.2. Default UBI images upgraded In Red Hat build of Quarkus 3.15, the following default UBI images were upgraded: ubi-minimal is upgraded to version 8.10 openjdk-17-runtime is upgraded to version 1.20 openjdk-21-runtime is upgraded to version 1.20 1.3.2.3. Extension annotation processor redevelopment Red Hat build of Quarkus 3.15 introduces a new architecture for the extension annotation processor and redevelops how configuration documentation is generated. Note This update is relevant for users who develop extensions for Red Hat build of Quarkus. The extension annotation processor has two main purposes: Generating files that the Red Hat build of Quarkus build and runtime requires. For example, the list of build steps or the list of configuration roots. Generating the documentation for the configuration properties of the extension. With this redevelopment, the annotation processor architecture is streamlined and separates the files needed to build the extension from those needed to generate the documentation. Previously, the extension annotation processor generated the configuration documentation in the root target/generated/config directory. Now, the extension annotation processor builds a model of the configuration, which can then be output in various required formats, such as AsciiDoc. For more information, see the following Quarkus resources: Migration guide 3.14 Configuration section of the Quarkus "Writing your own extension" guide Mapping configuration to objects 1.3.2.4. Interception of producer methods and synthetic beans introduced ArC is the Contexts and Dependency Injection (CDI) implementation of Red Hat build of Quarkus. By default, interception is only supported for the managed beans, also known as class-based beans. Red Hat build of Quarkus 3.15 introduces the InterceptionProxy API and the @BindingsSource annotation, supporting the interception of producer methods and synthetic beans. The InterceptionProxy API creates a proxy that applies @AroundInvoke interceptors before forwarding the method call to the target instance. With the @BindingsSource annotation, you set interceptor bindings in case the intercepted class is external and cannot be changed. For more information, see the Quarkus Contexts and dependency injection guide. 1.3.2.5. Option to disable live reload introduced Red Hat build of Quarkus 3.15 introduces the quarkus.live-reload.enabled configuration property with which you can turn off automatic live reload when you are using dev mode with the Dev services feature. By default, this property is set to true . To disable automatic live reload, set it to false . 1.3.2.6. quarkus config command updated Red Hat build of Quarkus 3.15 introduces the following updates to the quarkus config command. The quarkus config encrypt subcommand is updated to change the secret option to a parameter. Previously, to encrypt a value, you ran the following command: Now, you run: The quarkus config set subcommand is updated to change the name and value options to parameters. Previously, to set a configuration, you ran the following command: Now, you run: Also, with this release, omitting the value parameter from a configuration command no longer removes the existing configuration from the application.properties file. Instead, to remove a configuration, use the following command, replacing <abc> with the configuration property name: Note The Quarkus CLI is intended for development purposes, including tasks such as creating, updating, and building Quarkus projects. However, Red Hat does not support using the Quarkus CLI in production environments. For more information, see the Quarkus Secrets in configuration guide. 1.3.3. Data 1.3.3.1. Flyway upgraded to 10.10 In Red Hat build of Quarkus 3.15, the Flyway extension is upgraded to Flyway 10.10. For more information, see the Quarkus Using Flyway guide. 1.3.3.2. Hibernate ORM build time optimized for large models Red Hat build of Quarkus 3.15 introduces enhancements that accelerate the Hibernate Object-Relational Mapping (ORM) build time for large entity models. In particular, it is anticipated that these enhancements will make the Live Reload feature of the Quarkus dev mode more responsive for applications with large entity models. 1.3.3.3. Hibernate ORM upgraded to version 6.6 In Red Hat build of Quarkus 3.15, Hibernate ORM is upgraded to version 6.6. For more information, see the following resources: Hibernate ORM 6.6 migration guide Hibernate ORM 6.6 user guide Quarkus Using Hibernate ORM and Jakarta Persistence guide 1.3.3.4. Hibernate Reactive upgraded to version 2.4 In Red Hat build of Quarkus 3.15, the Hibernate Reactive extension is upgraded to version 2.4. For more information, see the Quarkus Hibernate Reactive guide. 1.3.3.5. Hibernate Search upgraded to version 7.2 In Red Hat build of Quarkus 3.15, Hibernate Search is upgraded to version 7.2. Hibernate Search offers indexing and full-text search capabilities to your Red Hat build of Quarkus applications. To learn more about Hibernate Search, see the following resources: Quarkus Use Hibernate Search with Hibernate ORM and Elasticsearch guide Hibernate ORM 7.2 migration guide Hibernate Search 7.2 reference documentation 1.3.3.6. MongoDB client upgraded to version 5.1 In Red Hat build of Quarkus 3.15, the MongoDB client is upgraded from version 4.11 to version 5.1. 1.3.4. Native 1.3.4.1. Native image agent integration Red Hat build of Quarkus 3.15 introduces integration with the native image agent, which you can use to integrate libraries or components not yet supported by Red Hat build of Quarkus when compiling applications into native images. With this integration, you can use JDK APIs where extensive native image configuration is needed. You can also run integration tests for your applications in JVM mode with the native image agent. The configuration generated by the agent helps you get started with using unsupported libraries and running applications as native executables. This integration is available only with Apache Maven. Note Newly generated projects automatically come with the appropriate configuration in the pom.xml . For more information, see the Quarkus Native reference guide. 1.3.5. Observability 1.3.5.1. Observability Dev Services extensions introduced Red Hat build of Quarkus 3.15 introduces the quarkus-observability-devservices and quarkus-observability-devservices-lgtm extensions for Dev Services, supporting the OpenTelemetry LGTM (OTel LGTM) Docker image: You can update the pom.xml file to add each of these extensions as dependencies. For example: <dependency> <groupId>io.quarkus</groupId> <artifactId>quarkus-observability-devservices-lgtm</artifactId> <version>USD{project.version}</version> <scope>provided</scope> </dependency> For more information, see the following Quarkus resources: Observability dev services Observability section of the "Dev Services overview" guide Observability dev services with Grafana OTEL LGTM 1.3.5.2. OpenTelemetry and instrumentation upgraded With Red Hat build of Quarkus 3.15, the OpenTelemetry (OTel) SDK version is upgraded from 1.32 to 1.39. Also, OTel instrumentation is upgraded from version 1.32 to 2.50. These upgrades introduce the following breaking changes: HTTP semantic conventions are changed. For more information, see the list of changes here: HTTP semantic convention stability migration . The quarkus.otel.semconv-stability.opt-in system property was removed because users can no longer opt in. In the case of table creation, database span names have changed. The deprecated annotation for io.opentelemetry.extension.annotations.WithSpan is removed. From Red Hat build of Quarkus 3.15, you must use the new io.opentelemetry.instrumentation.annotations.WithSpan . For more information, see Changes that affect compatibility with earlier versions . 1.3.5.3. OpenTelemetry support when using Quarkus Redis client Red Hat build of Quarkus 3.15 introduces support for tracing when using the quarkus-redis-client extension with OpenTelemetry (OTel). Red Hat build of Quarkus provides manual and automatic instrumentation for tracing. You must place this OpenTelemetry Redis implementation under the instrumentation of the quarkus-opentelemetry extension. Tracing data includes, among other attributes, the request statement, database instance, and peer address. Status codes and messages are available in error spans. For more information, see the Quarkus Using the Quarkus Redis client guide. 1.3.6. Security 1.3.6.1. Annotations for authentication mechanism selection for REST endpoints With Red Hat build of Quarkus 3.15, you can use annotations to enable an authentication mechanism specific to a Jakarta REST endpoint. Because you can only use annotations to select authentication mechanisms after a REST endpoint has been matched, this feature is enabled only when proactive authentication is disabled, that is, when quarkus.http.auth.proactive is set to false . For more information, see the Use annotations to enable path-based authentication for Jakarta REST endpoints section of the "Quarkus authentication mechanisms" guide. 1.3.6.2. @ClientBasicAuth annotation introduced Red Hat build of Quarkus 3.15 introduces a new annotation, @ClientBasicAuth , which simplifies how you set an HTTP Authorization header with a Basic authentication username and password in the Red Hat build of Quarkus REST client. When using HTTP Basic authentication, the quarkus.rest.client.reactive.ClientBasicAuth annotation simplifies the configuration of the necessary authorization header. For example: @ClientBasicAuth(username = "USD{service.username}", password = "USD{service.password}") public interface SomeClient { } In this example, the service.username and service.password are configuration properties that you set at runtime with the appropriate username and password that grant access to the target service. For more information, see the Quarkus Using the REST client guide. 1.3.6.3. Issue-based resolution of static OIDC tenants In Red Hat build of Quarkus 3.15, you can resolve static OpenID Connect (OIDC) tenants that support Bearer token authentication by using the issuer of the access token. For this issue-based resolution to work, ensure the following conditions are met: The access token must be in a JSON Web Token (JWT) format and contain an issuer ( iss ) token claim. Only OIDC tenants with the application type service or hybrid are considered. These tenants must have a token issuer discovered or configured. You must enable the token issuer with the quarkus.oidc.resolve-tenants-with-issuer property. For more information, see the Quarkus Using OIDC multitenancy guide. 1.3.6.4. OIDC redirect filters introduced When a user is redirected to an OpenID Connect (OIDC) provider to authenticate, the redirect must indicate to the provider where to direct the user when the authentication is complete. Red Hat build of Quarkus 3.15 introduces OpenID Connect (OIDC) redirect filters to filter OIDC redirects. You can register one or more io.quarkus.oidc.OidcRedirectFilter implementations to filter OIDC redirects to OIDC authorization and logout endpoints, and to filter local redirects to custom error and session-expired pages. With OidcRedirectFilter , you can also add additional query parameters, response headers, and set new cookies for all redirect requests. For more information, see the OIDC redirects filter section of the Quarkus "OIDC authorization code flow mechanism" guide. 1.3.6.5. OIDC session-expired page introduced Previously, if a user session could not be refreshed, the currently authenticated user was redirected to the OpenID Connect (OIDC) provider to re-authenticate. However, it might not be obvious to the user why they need to reauthenticate. With Red Hat build of Quarkus 3.15, you can now configure that the user is instead redirected to a public, application-specific, session-expired page. This page informs the user that the session has expired and advises them to re-authenticate by following a link to a secured application Welcome page. To enable this page, specify the quarkus.oidc.authentication.session-expired-page relative path property. For more information, see the Quarkus OIDC authorization code flow mechanism guide. 1.3.6.6. OIDC TokenCertificateValidator annotation introduced Red Hat build of Quarkus 3.15 enhances security with the introduction of the OpenID Connect (OIDC) TokenCertificateValidator annotation. You can use this annotation to add a custom certificate chain validation check to a token's certificate chain in addition to the default chain validation. For more information, see the Quarkus OIDC bearer token authentication guide. 1.3.6.7. Security events exported as OpenTelemetry events With Red Hat build of Quarkus 3.15, you can export security events as OpenTelemetry (OTel) events inside spans, if the security context is available. This feature adds user identification and roles to the span attributes. To enable this feature, set the following configuration property to true in the application.properties file: quarkus.otel.security-events.enabled=true For more information, see the following Quarkus resources: Security tips and tricks Using OpenTelemetry 1.3.6.8. Signed OIDC UserInfo accepted During OpenID Connect (OIDC) authorization, if an ID token does not provide enough information about a currently authenticated user, you can get more information in JSON format from the UserInfo endpoint. With Red Hat build of Quarkus 3.15, UserInfo returned as a signed JSON Web Token (JWT) is supported. Red Hat build of Quarkus verifies this signed JWT token, then the UserInfo is initialized with secured JSON data. 1.3.7. Web 1.3.7.1. Centralized TLS registry introduced Red Hat build of Quarkus 3.15 introduces a new Transport Layer Security (TLS) registry extension, quarkus-tls-registry , which includes the following features: Centralized TLS configuration for an application Previously, TLS configuration was spread across multiple Red Hat build of Quarkus extensions, which sometimes led to inconsistencies. With the introduction of the TLS registry, you can now complete TLS configuration in one place, the application.properties file, then reference it from multiple places in the application. Centralized configuration of Mailer, HTTP server, REST client, and messaging components Mailer You can use the TLS registry to configure the quarkus-mailer extension. To avoid conflicts with other TLS configurations, using a named TLS configuration stored in the TLS registry is required. You can define separate named configurations by using the quarkus.tls.<name>.* properties. HTTP server You can configure the HTTP server and define separate named configurations for specific connections by using quarkus.tls.<name>.* properties. REST client You can configure the quarkus-rest-client extension by using the TLS registry instead of a specific configuration. Quarkus messaging You can use the TLS registry to configure Quarkus messaging channels by using the mp.messaging.incoming.your-channel.tls-configuration-name=<name> and quarkus.tls.<name>.* properties. For more information, see individual Quarkus messaging guides. For more information, see the Quarkus TLS registry reference guide. 1.3.7.2. HTTP pass-through proxy for REST client When you use the Quarkus REST client, you might want to examine requests sent to the server, and when dealing with HTTPS connections, the easiest way to inspect the traffic is through a pass-through proxy. With Red Hat build of Quarkus 3.15, you can add an HTTP pass-through proxy for REST clients. You can use this proxy as a target for Wireshark to get the content of requests that the REST client sends. To enable the proxy, set the quarkus.rest-client.<client name>.enable-local-proxy property to true . Note This feature is only available with the Quarkus REST client and only in dev mode. 1.3.7.3. Run custom logic when the HTTP server starts With Red Hat build of Quarkus 3.15, Vert.x HTTP is enhanced. Now, you can run custom actions when the HTTP server starts. To do so, you declare an asynchronous Context and Dependency Injection (CDI) observer method. Then, when the corresponding HTTP server starts listening on the configured host and port, Red Hat build of Quarkus fires the following CDI events: io.quarkus.vertx.http.HttpServerStart io.quarkus.vertx.http.HttpsServerStart io.quarkus.vertx.http.DomainSocketServerStart For more information, see the Quarkus HTTP reference guide. 1.4. Support and compatibility You can find detailed information about the supported configurations and artifacts that are compatible with Red Hat build of Quarkus 3.15 and the high-level support lifecycle policy on the Red Hat Customer Support portal as follows: For a list of supported configurations, OpenJDK versions, and tested integrations, see Red Hat build of Quarkus Supported configurations . For a list of the supported Maven artifacts, extensions, and BOMs for Red Hat build of Quarkus, see Red Hat build of Quarkus Component details . For general availability, full support, and maintenance support dates for all Red Hat products, see Red Hat Application Services Product Update and Support Policy . 1.4.1. Product updates and support lifecycle policy In Red Hat build of Quarkus, a feature release can be either a major release or a minor release: A major release introduces new features and a support life cycle (full and maintenance) for a minimum of 3 years. A minor release introduces new features or changes that do not affect compatibility with earlier releases (breaking changes). The latest minor version is fully supported, and the version is considered in maintenance for six months, starting when a new minor version is released. For more information, see Red Hat Life Cycle and Support Policies . Red Hat build of Quarkus release version numbers are directly aligned with the Long-Term Support (LTS) versions of the Quarkus community project . For more information, see the Long-Term Support (LTS) for Quarkus blog post. The version numbering of a Red Hat build of Quarkus feature release matches the Quarkus community version on which it is based. Important Red Hat does not release a productized version of Quarkus for every version the community releases. The cadence of the Red Hat build of Quarkus feature releases is about every six months. Red Hat build of Quarkus provides full support for a feature release right up until the release of a subsequent version. When a feature release is superseded by a new version, Red Hat continues to provide a further six months of maintenance support for the release, as outlined in the following support lifecycle chart [Fig. 1]. Figure 1. Feature release cadence and support lifecycle of Red Hat build of Quarkus During the full support phase and maintenance support phase of a release, Red Hat also provides 'service-pack (SP)' updates and 'micro' releases to fix bugs and Common Vulnerabilities and Exposures (CVE). New features in subsequent feature releases of Red Hat build of Quarkus can introduce enhancements, innovations, and changes to dependencies in the underlying technologies or platforms. For a detailed summary of what is new or changed in a successive feature release, see New features, enhancements, and technical changes . While most of the features of Red Hat build of Quarkus continue to work as expected after you upgrade to the latest release, there might be some specific scenarios where you need to change your existing applications or do some extra configuration to your environment or dependencies. Therefore, before upgrading Red Hat build of Quarkus to the latest release, always review the Changes that affect compatibility with earlier versions and Deprecated components and features sections of the release notes. For detailed information about the product lifecycle, timelines, and support policies of Red Hat build of Quarkus, log in to the Red Hat Customer Portal and see the Knowledgebase article, Red Hat build of Quarkus lifecycle and support policies . 1.4.2. Tested and verified environments Red Hat build of Quarkus 3.15 is available on the following versions of Red Hat OpenShift Container Platform: 4.17, 4.12, and Red Hat Enterprise Linux 8.10. For a list of supported configurations, log in to the Red Hat Customer Portal and see the Knowledgebase solution Red Hat build of Quarkus Supported configurations . 1.4.3. Development support Red Hat provides development support for the following Red Hat build of Quarkus features, plugins, extensions, and dependencies: Features Continuous Testing Dev Services Dev UI Local development mode Remote development mode Plugins Maven Protocol Buffers Plugin 1.4.3.1. Development tools Red Hat provides development support for using Quarkus development tools, including the Quarkus CLI and the Maven and Gradle plugins, to prototype, develop, test, and deploy Red Hat build of Quarkus applications. Red Hat does not support using Quarkus development tools in production environments. For more information, see the Red Hat Knowledgebase article Development Support Scope of Coverage . 1.5. Deprecated components and features The components and features listed in this section are deprecated with Red Hat build of Quarkus 3.15. They are included and supported in this release. However, no enhancements will be made to these components and features, and they might be removed in the future. For a list of the components and features that are deprecated in this release, log in to the Red Hat Customer Portal and view the Red Hat build of Quarkus Component details page. 1.5.1. Deprecation of Apache Derby The Apache Derby database is deprecated in Red Hat build of Quarkus 3.15 and is planned to be removed in a future release. Red Hat will continue to provide development support for Apache Derby during the current release lifecycle. 1.5.2. Deprecation of OpenShift Service Binding Operator The OpenShift Service Binding Operator is deprecated in OpenShift Container Platform 4.13 and later and is planned to be removed in a future OpenShift Container Platform release. 1.6. Technology previews This section lists features and extensions that are now available as a Technology Preview in Red Hat build of Quarkus 3.15. Important Technology Preview features are not supported with Red Hat production service level agreements (SLAs), might not be functionally complete, and Red Hat recommends that you do not use them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For more information about Red Hat Technology Preview features, see Technology Preview Features Scope . 1.6.1. Cert-manager support and periodic reload of TLS certificates With Red Hat build of Quarkus 3.15, you can configure automatic periodic reloading of TLS certificates either from the TLS registry or, when running in Kubernetes, by using cert-manager . This feature is introduced as a Technology Preview. Automatic periodic reloading of TLS certificates The TLS registry includes a built-in mechanism to periodically check the file system for certificate changes and reload them. You configure the reload interval by using the reload-period property, which defines how often certificates are reloaded. You can reload TLS certificate files (keystore and truststore) for the HTTP server. The certificate files are reloaded from the same location from where they were initially loaded, and only certificates that have been modified since the last reload are included. If the reloading fails, the HTTP server continues to use the previously-loaded certificates. The TLS registry is automatically added to your Red Hat build of Quarkus project when you use a compatible extension. For example, if your application uses Quarkus REST, gRPC, or Reactive routes, the TLS registry is automatically added to your project. Using cert-manager When running Kubernetes, you can use the cert-manager feature to automatically generate, renew, and store certificates. cert-manager produces a secret with the key stores and trust stores. Configuring the TLS registry is the same as when using Kubernetes secrets. For more information, see the Quarkus TLS registry reference guide. 1.6.2. Generate reflection-free Jackson serializers With Red Hat build of Quarkus 3.15, you can generate faster reflection-free Jackson serializers for types that are serialized by Quarkus REST. This feature is introduced as a Technology Preview. Jackson serialization converts objects into their JSON representation by introspecting them through reflection. With this update, you can automatically generate implementations of the Jackson StdSerializer at build time, one for each class to be converted in JSON. Red Hat build of Quarkus then uses the generated serializers at runtime to perform the JSON serialization of the objects returned by a REST endpoint. By default, this feature is not enabled. To enable it, set the following configuration property to true . quarkus.rest.jackson.optimization.enable-reflection-free-serializers=true . For more information, see the Reflection-free Jackson serialization section of the Quarkus "Writing REST services with Quarkus REST" guide. 1.6.3. Infinispan cache extension introduced Red Hat build of Quarkus 3.15 introduces a new extension, quarkus-infinispan-cache . Previously, Red Hat build of Quarkus used Caffeine as a backend for Quarkus cache. With this release, you can use Infinispan as the cache backend instead. Unlike Caffeine, which runs in-process, Infinispan operates externally to Quarkus, ensuring that the cache lifecycle is independent of the application lifecycle. Additionally, Infinispan is a distributed system, so the failure of one node does not impact the operation of other nodes. In Red Hat build of Quarkus 3.15, the Infinispan component is upgraded to version 15.0. For more information, see the Quarkus Infinispan cache guide. 1.6.4. JDK Flight Recorder extension introduced Red Hat build of Quarkus 3.15 introduces the JDK Flight Recorder (JFR) extension, quarkus-jfr , as a Technology Preview. The JFR is a built-in JVM tool for monitoring and diagnosing Java application performance. It captures event data like CPU usage, memory, and thread activity. To identify bottlenecks and optimize performance, add the JFR to your application, configure the events to record, and analyze the data. The quarkus-jfr extension is compatible with the following extensions: quarkus-rest quarkus-opentelemetry For more information, see the Quarkus Using Java Flight Recorder guide. 1.6.5. OpenTelemetry metrics data creation and reporting You can use OpenTelemetry (OTel) to provide metrics for interactive web applications. With Red Hat build of Quarkus 3.15, you can create and export your OTel metrics data by using the quarkus-opentelemetry extension. This feature is introduced as a Technology Preview and is disabled by default. To enable OTel metrics, specify the following setting at build time: quarkus.otel.metrics.enabled=true For more information, see the Quarkus Using OpenTelemetry metrics guide. 1.6.6. MongoDB tracing enhanced Red Hat build of Quarkus 3.15 enhances MongoDB tracing by introducing integration with the quarkus-opentelemetry extension. This enhancement is introduced as a Technology Preview and is disabled by default. To use tracing with MongoDB, add the quarkus-opentelemetry extension to your project, and specify the following setting: quarkus.mongodb.tracing.enabled=true For more information, see the Quarkus Using the MongoDB client guide. 1.7. Changes that affect compatibility with earlier versions This section describes changes in Red Hat build of Quarkus 3.15 that affect the compatibility of applications built with earlier product versions. Review these breaking changes and take the necessary steps to ensure that your applications continue functioning after updating them to Red Hat build of Quarkus 3.15. To update your application projects to Red Hat build of Quarkus 3.15, see the Migrating applications to Red Hat build of Quarkus 3.15 guide. 1.7.1. Compatibility 1.7.1.1. Spring compatibility layer updated to align with Spring Boot 3 With Red Hat build of Quarkus 3.15, the quarkus-spring-data-rest-extension was upgraded to align with the latest Spring Boot 3 API updates. If you use the PagingAndSortingRepository interface in your code, this upgrade might introduce breaking changes. Previously, the PagingAndSortingRepository extended the CrudRepository , which allowed your custom repository to inherit the methods from the CrudRepository . To resolve any issues related to this change, you must update your custom repository to extend either ListCrudRepository or CrudRepository directly. This adjustment ensures continued access to the required methods and maintains compatibility with the updated architecture. 1.7.2. Core 1.7.2.1. Dev Services startup detection change In Red Hat build of Quarkus 3.15, the method for determining whether Dev Services should start has changed. Previously, to decide whether to start Dev Services, Red Hat build of Quarkus checked if a configuration property was defined without expanding it. However, this approach caused issues if the property expanded to an empty value. Now, Red Hat build of Quarkus first checks whether the expanded property is empty. This change might result in Dev Services starting unexpectedly where they didn't before, in cases when the expanded property ends up being empty. Most Dev Services start when a given property is not provided, for instance, the JDBC URL. Due to this change, you should adjust your configuration properties to include a default value, ensuring that the expanded property is not empty. For example, if you use the quarkus-test-oidc-server component to mock the OpenID Connect (OIDC) server, and your application.properties file contains: Change the property value to: This way, if keycloak.url is not defined, the default replaced-by-test-resource value prevents the property from expanding to an empty value, thereby avoiding the unintended startup of Dev Services. If a variable is not defined in an expression, the whole expression will be empty. Note For this particular example, this change is applied automatically by running quarkus update . However, for other use cases, you might need to apply the change manually. 1.7.2.2. GraalVM SDK updates Red Hat build of Quarkus 3.15 updates the GraalVM SDK dependencies to version 23.1.2, correcting an earlier oversight and ensuring compatibility with the latest GraalVM features. If you develop extensions with GraalVM substitutions, replace the org.graalvm.sdk:graal-sdk dependency with org.graalvm.sdk:nativeimage . The nativeimage artifact includes only the required classes for substitutions, making it more streamlined. You can apply this change by running the automated update described in the Migrating applications to Red Hat build of Quarkus 3.15 guide. Important JDK 17 requirement: GraalVM SDK 23.1.2 requires a minimum of JDK 17 at runtime. 1.7.2.3. Infinispan 15 component upgrade In Red Hat build of Quarkus 3.15, the Infinispan 15 component is upgraded to version 15.0. In earlier releases, before Infinispan 15 integration, you ran queries by using the following .Query.java code: @Inject RemoteCache<String, Book> booksCache; ... QueryFactory queryFactory = Search.getQueryFactory(booksCache); Query query = queryFactory.create("from book_sample.Book"); List<Book> list = query.execute().list(); However, with this release, this code no longer works because RemoteCache is now an @ApplicationScoped proxy bean and Search.getQueryFactory raises a ClassCastException . To resolve this, remove the indirection by using the query method in the RemoteCache API as follows: @Inject RemoteCache<String, Book> booksCache; ... Query<Book> query = booksCache.<Book>query("from book_sample.Book"); List<Book> list = query.execute().list(); You must apply this change manually. It is not covered by the automated update described in the Migrating applications to Red Hat build of Quarkus 3.15 guide. 1.7.2.4. Packaging configuration changes In Red Hat build of Quarkus 3.15, the following packaging-related properties have been renamed or changed. If you use the original properties in your configuration, they still work, but a warning is displayed. You can apply this change by running the automated update described in the Migrating applications to Red Hat build of Quarkus 3.15 guide. Table 1.1. Update the following properties in your configuration Original names Current names quarkus.package.type For JAR builds, use quarkus.package.jar.type with a valid JAR type: fast-jar , uber-jar , mutable-jar , or legacy-jar (deprecated). For native builds, set quarkus.native.enabled to true . For native sources builds, also set quarkus.native.sources-only to true . You can also disable JAR building by setting quarkus.package.jar.enabled to false . quarkus.package.create-appcds quarkus.package.jar.appcds.enabled quarkus.package.appcds-builder-image quarkus.package.jar.appcds.builder-image quarkus.package.appcds-use-container quarkus.package.jar.appcds.use-container quarkus.package.compress-jar quarkus.package.jar.compress quarkus.package.filter-optional-dependencies quarkus.package.jar.filter-optional-dependencies quarkus.package.add-runner-suffix quarkus.package.jar.add-runner-suffix Note: This configuration property generally only applies when building uber-JARs. quarkus.package.user-configured-ignored-entries quarkus.package.jar.user-configured-ignored-entries quarkus.package.user-providers-directory quarkus.package.jar.user-providers-directory quarkus.package.included-optional-dependencies quarkus.package.jar.included-optional-dependencies quarkus.package.include-dependency-list quarkus.package.jar.include-dependency-list quarkus.package.decompiler.version , quarkus.package.vineflower.version No replacement; these properties are now ignored. quarkus.package.decompiler.enabled , quarkus.package.vineflower.enabled quarkus.package.jar.decompiler.enabled quarkus.package.decompiler.jar-directory , quarkus.package.vineflower.jar-directory quarkus.package.jar.decompiler.jar-directory quarkus.package.manifest.attributes.* quarkus.package.jar.manifest.attributes.* quarkus.package.manifest.sections.*.* quarkus.package.jar.manifest.sections.*.* quarkus.package.manifest.add-implementation-entries quarkus.package.jar.manifest.add-implementation-entries Update any code and configuration files to reflect these changes and stop warning messages during the build process. 1.7.2.5. ProfileManager and ProfileManager#getActiveProfile removed In Red Hat build of Quarkus 3.15, the deprecated ProfileManager class and ProfileManager#getActiveProfile method are removed because the ProfileManager did not handle multiple profiles. With this removal, the following configuration change is required: To retrieve an active profile, use the io.quarkus.runtime.configuration.ConfigUtils#getProfiles API. You must apply this change manually. It is not covered by the automated update described in the Migrating applications to Red Hat build of Quarkus 3.15 guide. 1.7.2.6. The quarkus-app directory is now created only for fast-jar packages In earlier releases, an unintended behavior was observed where a quarkus-app directory was always generated in the build system's output directory, regardless of the type of artifact produced. In Red Hat build of Quarkus 3.15, the build process creates the quarkus-app directory only for fast-jar packages, which is the default artifact type. If you configure the build for a different artifact type, the quarkus-app directory is not created. 1.7.2.7. Required adjustments for extension developers In Red Hat build of Quarkus 3.15, the extension annotation processor used to generate runtime files and configuration documentation has been redeveloped, offering more flexibility but with new constraints: Mixing the legacy @ConfigRoot with the new @ConfigMapping approach in the same module is no longer allowed. If you use only @ConfigMapping , you do not need to make any changes. For legacy @ConfigRoot , inform the annotation processor by adding the following to your maven-compiler-plugin configuration: <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <configuration> <annotationProcessorPaths> <path> <groupId>io.quarkus</groupId> <artifactId>quarkus-extension-processor</artifactId> <version>USD{quarkus.version}</version> </path> </annotationProcessorPaths> <compilerArgs> <arg>-AlegacyConfigRoot=true</arg> </compilerArgs> </configuration> </plugin> If no configuration annotations exist in the test classes, this flag can trigger warnings when compiling test classes. To avoid this, enable the annotation processor only for default-compile execution: <plugin> <artifactId>maven-compiler-plugin</artifactId> <executions> <execution> <id>default-compile</id> <configuration> <annotationProcessorPaths> <path> <groupId>io.quarkus</groupId> <artifactId>quarkus-extension-processor</artifactId> <version>USD{quarkus.version}</version> </path> </annotationProcessorPaths> <compilerArgs> <arg>-AlegacyConfigRoot=true</arg> </compilerArgs> </configuration> </execution> </executions> </plugin> Moving to the new @ConfigMapping interface is encouraged, but support for legacy @ConfigRoot classes is planned to continue for a while to ensure a smooth migration. Deprecation plans are planned to be announced at a later date. You must apply this change manually. It is not covered by the automated update described in the Migrating applications to Red Hat build of Quarkus 3.15 guide. 1.7.3. Data 1.7.3.1. Database version verified on startup With Red Hat build of Quarkus 3.15, the Hibernate ORM extension verifies that the database version it connects to at runtime is at least as high as the one configured at build time. This verification occurs even when the configuration relies on default settings targeting the minimum database versions supported by Red Hat build of Quarkus. This update aims to alert application developers aware if they try to use a database version that Hibernate ORM or Red Hat build of Quarkus no longer support. If you try to use a database version that is no longer supported, Red Hat build of Quarkus does not start and throws an exception. This change affects applications that rely on the following database versions: DB2 earlier than version 10.5 Derby earlier than version 10.15.2 Oracle database earlier than version 19.0 MariaDB earlier than version 10.6 Microsoft SQL Server earlier than version 13 (2016) MySQL earlier than version 8.0 PostgreSQL earlier than version 12.0 If you cannot upgrade the database to a supported version, you can still try to use it, although some features might not work. To continue using an earlier, unsupported database version, set the db-version explicitly and, if necessary, set the dialect also. You must apply this change manually. It is not covered by the automated update described in the Migrating applications to Red Hat build of Quarkus 3.15 guide. For more information, see the following resources: Supported databases section of the Quarkus "Using Hibernate ORM and Jakarta Persistence" guide Hibernate ORM: Supported dialects Hibernate ORM: Community dialects 1.7.3.2. Dev Services default images updates In Red Hat build of Quarkus 3.15, the default images for several Dev Services have been updated to the following versions: PostgreSQL version 16 MySQL version 8.4 MongoDB version 7.0 Elasticsearch version 8.15 OpenSearch version 2.16 You can apply this change by running the automated update described in the Migrating applications to Red Hat build of Quarkus 3.15 guide. To use a specific version or distribution of these services, you must manually override the default container image in your application properties. For more information, see the Configuring the image section of the Quarkus "Dev Services for Elasticsearch" guide. 1.7.3.3. Hibernate ORM auto-flush optimization In Red Hat build of Quarkus 3.15, the Hibernate Object/Relational Mapping (ORM) auto-flush feature is optimized. Now, by default, before running a Hibernate Query Language (HQL), Java Persistence Query Language (JPQL), or native query, Hibernate ORM flushes only pending changes to the database if it detects that these changes might impact the query results. In most cases, this optimization will improve the performance of your applications, such as with more efficient batching, however, the following issues might occur: If you are running a native query, auto-flushing requires you to specify relevant entity types on the query. For more information, see the Hibernate ORM user guide . If pending changes impact only the target tables of the foreign keys used in the query, but those target tables are not used in the query, auto flushing does not happen. If you want to revert to behavior and choose an alternative default value, the quarkus.hibernate-orm.flush.mode configuration property is introduced. Set this property to always : quarkus.hibernate-orm.flush.mode=always . You must apply this change manually. It is not covered by the automated update described in the Migrating applications to Red Hat build of Quarkus 3.15 guide. For more information, see the following resources: Hibernate ORM 6.6 migration guide Hibernate ORM 6.6 user guide 1.7.3.4. Hibernate ORM upgraded to version 6.6 In Red Hat build of Quarkus 3.15, Hibernate ORM extensions were upgraded to Hibernate ORM 6.6 and introduced the following breaking changes: Applications with certain forms of incorrect configuration, mapping, or queries might now also throw exceptions. Previously, they would issue only warnings or malfunctions. For example: An invalid creation attempt when merging an entity with a @GeneratedValue identifier or a @Version property set to a non-null value now fails. Previously, it created the entity in the database. For more information, see Merge versioned entity when row is deleted . Applying both @MappedSuperclass and @Embeddable on the same type is no longer allowed. For more information, see Explicit validation of annotated class types . Some features are now enabled by default, to avoid unexpected behaviors. For example: Embeddables with @Embeddable annotated subtypes now use discriminator-based inheritance by default. For more information, see link: Discriminator-based embeddable inheritance . In some instances, behavior was changed to comply with the Java Persistence API (JPA) specification. For more information, see Criteria:jakarta.persistence.criteria.Expression#as(Class) . For more information, see the following resources: Hibernate ORM 6.5 migration guide Hibernate ORM 6.6 migration guide Hibernate ORM 6.6 user guide 1.7.3.5. Hibernate Search database schema update for outbox-polling system tables The quarkus-hibernate-search-orm-outbox-polling extension relies on system tables in the database to which Hibernate ORM connects, and with Red Hat build of Quarkus 3.15, the schema of these system tables might change. If you use this extension, you need to migrate your database schema. For information about how to migrate your database schema, see the Outbox polling database tables section in the "Hibernate Search migration" guide. If you cannot update your database schema, apply the following settings to restore the defaults: For the default persistence unit, specify the following: quarkus.hibernate-search-orm.coordination.entity-mapping.agent.uuid-type=char quarkus.hibernate-search-orm.coordination.entity-mapping.outbox-event.uuid-type=char For named persistence units, specify the following: quarkus.hibernate-search-orm.<persistence-unit-name>.coordination.entity-mapping.agent.uuid-type=char quarkus.hibernate-search-orm.<persistence-unit-name>.coordination.entity-mapping.outbox-event.uuid-type=char You must apply this change manually. It is not covered by the automated update described in the Migrating applications to Red Hat build of Quarkus 3.15 guide. 1.7.3.6. Panache annotation processor removed for Hibernate ORM, Hibernate Reactive, and MongoDB In Red Hat build of Quarkus 3.15, the io.quarkus:quarkus-panache-common annotation processor has been removed because it is no longer required for externally defined entities when using Hibernate ORM with Panache, Hibernate Reactive with Panache, or MongoDB with Panache. In earlier releases, this annotation processor was automatically run when found in the classpath. If you had overridden the set of annotation processors in your build tool, you needed to add it explicitly. Remove all references to io.quarkus:quarkus-panache-common from the annotation processor list. You can apply this change by running the automated update described in the Migrating applications to Red Hat build of Quarkus 3.15 guide. Maven users Find and remove the io.quarkus:quarkus-panache-common annotation processor from your pom.xml file: <build> <plugins> <!-- other plugins --> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>3.13.0</version> <!-- Necessary for proper dependency management in annotationProcessorPaths --> <configuration> <annotationProcessorPaths> <path> <groupId>io.quarkus</groupId> <artifactId>quarkus-panache-common</artifactId> </path> </annotationProcessorPaths> </configuration> </plugin> <!-- other plugins --> </plugins> </build> Gradle users For Gradle builds, find and remove the io.quarkus:quarkus-panache-common annotation processor from your build.gradle file: dependencies { annotationProcessor "io.quarkus:quarkus-panache-common" } 1.7.4. Messaging 1.7.4.1. Changes to execution mode for synchronous methods in Quarkus Messaging In Red Hat build of Quarkus 3.15, the execution mode for synchronous methods in Quarkus Messaging extensions now defaults to worker threads. In earlier versions, these methods ran on the Vert.x event loop (I/O thread). For example, the following processing method is now called by default on a worker thread instead of the Vert.x I/O thread: package org.acme; import org.eclipse.microprofile.reactive.messaging.Incoming; import org.eclipse.microprofile.reactive.messaging.Outgoing; @Incoming("source") @Outgoing("sink") public Result process(int payload) { return new Result(payload); } To revert to the earlier behavior, you can use the quarkus.messaging.blocking.signatures.execution.mode configuration property. Possible values are: worker (default) event-loop (earlier behavior) virtual-thread You can also adjust the execution mode on a per-method basis by using the @Blocking and @NonBlocking annotations: package org.acme; import io.smallrye.common.annotation.NonBlocking; import org.eclipse.microprofile.reactive.messaging.Incoming; @Incoming("source") @NonBlocking public void consume(int payload) { // called on I/O thread } By annotating the method with @NonBlocking , you ensure it is called on the Vert.x event loop (I/O thread). Review your messaging methods to ensure they run in the required execution mode, and update your code or configuration as needed. You must apply this change manually. It is not covered by the automated update described in the Migrating applications to Red Hat build of Quarkus 3.15 guide. 1.7.4.2. SmallRye Reactive Messaging extensions renamed to Quarkus Messaging In Red Hat build of Quarkus 3.15, the SmallRye Reactive Messaging extensions have been renamed to quarkus-messaging-* to reflect their support for both reactive and blocking workloads. Maven relocations have been implemented. You can apply this change by running the automated update described in the Migrating applications to Red Hat build of Quarkus 3.15 guide. Replace all instances of the old extension names in your projects with the new names. Renamed extensions The following extensions have been renamed: Old Name New Name quarkus-smallrye-reactive-messaging quarkus-messaging quarkus-smallrye-reactive-messaging-amqp quarkus-messaging-amqp quarkus-smallrye-reactive-messaging-kafka quarkus-messaging-kafka quarkus-smallrye-reactive-messaging-mqtt quarkus-messaging-mqtt quarkus-smallrye-reactive-messaging-pulsar quarkus-messaging-pulsar quarkus-smallrye-reactive-messaging-rabbitmq quarkus-messaging-rabbitmq The configuration root has also been updated from quarkus.smallrye-reactive-messaging. to quarkus.messaging. . An automatic fallback mechanism is in place to revert to the old configuration properties, if necessary. Impact on extension developers If you are an extension developer, note that the following deployment-related artifacts have also been renamed: Old Name New Name quarkus-smallrye-reactive-messaging-deployment quarkus-messaging-deployment quarkus-smallrye-reactive-messaging-kotlin quarkus-messaging-kotlin quarkus-smallrye-reactive-messaging-amqp-deployment quarkus-messaging-amqp-deployment quarkus-smallrye-reactive-messaging-kafka-deployment quarkus-messaging-kafka-deployment quarkus-smallrye-reactive-messaging-mqtt-deployment quarkus-messaging-mqtt-deployment quarkus-smallrye-reactive-messaging-pulsar-deployment quarkus-messaging-pulsar-deployment quarkus-smallrye-reactive-messaging-rabbitmq-deployment quarkus-messaging-rabbitmq-deployment Update your code and configurations to reflect these changes. 1.7.5. Observability 1.7.5.1. All quarkus.opentelemetry.* configuration properties removed In Red Hat build of Quarkus 3.15, all configuration properties under the quarkus.opentelemetry.* namespace have been removed. These properties were deprecated and maintained for backward compatibility in versions 3.2 and 3.8. Because they are now removed in 3.15, you must make the following changes to migrate your applications: Update all properties from the quarkus.opentelemetry. namespace to the quarkus.otel. namespace so they align with the OpenTelemetry Java autoconfigure conventions . Update the sampler property from quarkus.opentelemetry.tracer.sampler to quarkus.otel.traces.sampler . The parent-based sampler property quarkus.opentelemetry.tracer.sampler.parent-based has been removed. To mark the sampler as parent-based, specify it directly in the quarkus.otel.traces.sampler property, as shown below. Table 1.2. Value mapping from the original to the new sampler configuration Old value New value New value (parent-based) on always_on parentbased_always_on off always_off parentbased_always_off ratio traceidratio parentbased_traceidratio Update your code and configurations to use these new properties and values. You must apply this change manually. It is not covered by the automated update described in the Migrating applications to Red Hat build of Quarkus 3.15 guide. 1.7.5.2. OpenTelemetry io.opentelemetry.extension.annotations.WithSpan annotation removed In Red Hat build of Quarkus 3.15, the deprecated annotation io.opentelemetry.extension.annotations.WithSpan has been removed. Update your code to use the new io.opentelemetry.instrumentation.annotations.WithSpan annotation. Review and change any configurations or code that rely on the old annotation to ensure compatibility with this update. You must apply this change manually. It is not covered by the automated update described in the Migrating applications to Red Hat build of Quarkus 3.15 guide. 1.7.5.3. OpenTelemetry new semantic conventions for HTTP In Red Hat build of Quarkus 3.15, the OpenTelemetry (OTel) SDK has been upgraded to version 1.39.0 and instrumentation to version 2.5.0. This upgrade enforces the new conventions defined in the OpenTelemetry HTTP semantic convention stability migration . It also completes the removal of the deprecated standards. Update any code or configurations that depend on those conventions. Additionally, the quarkus.otel.semconv-stability.opt-in system property has been removed because opting-in is no longer supported. Update any code or configurations that depend on this property. You must apply this change manually. It is not covered by the automated update described in the Migrating applications to Red Hat build of Quarkus 3.15 guide. 1.7.5.4. OpenTelemetry REST client span name changes In Red Hat build of Quarkus 3.15, the OpenTelemetry (OTel) REST client span names now include both the HTTP request method and path; for example, GET /hello . Earlier REST client span names included only the HTTP method. Update any code or configurations that depend on the specific format of REST client span names. You must apply this change manually. It is not covered by the automated update described in the Migrating applications to Red Hat build of Quarkus 3.15 guide. 1.7.5.5. OpenTelemetry (OTel) span names generated by database operations changed In Red Hat build of Quarkus 3.15, the span names generated by database operations have changed due to updates in the libraries we use. For example, before this change, the old span name for creating a database table was DB Query . Now, with this change, the new span name is CREATE TABLE {table_name} . This new naming convention provides more descriptive and meaningful span names that accurately reflect the specific database operations performed. As a result, you might notice different names for spans generated by database operations in your observability tools. Review and update any custom monitoring configurations, alerts, or dashboards that rely on the old span names to accommodate the new naming convention. You must apply this change manually. It is not covered by the automated update described in the Migrating applications to Red Hat build of Quarkus 3.15 guide. For more information about the database span naming conventions and best practices, see the OpenTelemetry Database Span Semantic Conventions specification. 1.7.5.6. SmallRye health configuration properties relocated In earlier versions, some configuration properties were incorrectly located under the quarkus.health configuration root. In Red Hat build of Quarkus 3.15, those properties have relocated to the quarkus.smallrye-health configuration root for consistency: quarkus.health.extensions.enabled has been moved to quarkus.smallrye-health.extensions.enabled quarkus.health.openapi.included has been moved to quarkus.smallrye-health.openapi.included In Red Hat build of Quarkus 3.15, the properties with the old configuration roots have been deprecated and are planned to be removed in a future release. Update any code or configurations to use the new property locations. You must apply this change manually. It is not covered by the automated update described in the Migrating applications to Red Hat build of Quarkus 3.15 guide. 1.7.6. Security 1.7.6.1. Keystore and truststore default format changed With Red Hat build of Quarkus 3.15, Java Keystroke (JKS) is no longer the default keystore and truststore format. Instead, Red Hat build of Quarkus determines the format based on the file extension, as follows: .pem , .crt , and .key files are read as Privacy Enhanced Mail (PEM) certificates and keys .jks , .keystore , and .truststore files are read as JKS keystores and truststores .p12 , .pkcs12 , and .pfx files are read as PKCS12 keystores and truststores If your file does not use one of these extensions, you must set the file format. For example, to specify the JKS format, set the following configuration values: quarkus.http.ssl.certificate.key-store-file-type=JKS quarkus.http.ssl.certificate.trust-store-file-type=JKS Note To specify P12 or PEM formats, set P12 or PEM instead of JKS. 1.7.6.2. OpenID Connect (OIDC) UserInfo acquisition enforced when UserInfo is injected In Red Hat build of Quarkus 3.15, the quarkus.oidc.authentication.user-info-required property is now automatically set to true when io.quarkus.oidc.UserInfo is injected into a REST endpoint. This change removes the need to configure this property manually, because UserInfo is typically injected when its use is intended. However, in more complex setups where multiple OIDC tenants secure endpoints, and some tenants do not support UserInfo , this change might lead to tenant initialization failures. This happens only when a tenant that does not support UserInfo is still configured to acquire it, potentially causing requests secured by that tenant to fail. To avoid such failures in multi-tenant setups, set the tenant-specific quarkus.oidc.<tenant-id>.authentication.user-info-required property to false for tenants that do not support UserInfo . This ensures that only tenants that support UserInfo enforce its acquisition. You must apply this change manually. It is not covered by the automated update described in the Migrating applications to Red Hat build of Quarkus 3.15 guide. 1.7.7. Tooling 1.7.7.1. JUnit Pioneer version no longer enforced In Red Hat build of Quarkus 3.15, the Quarkus BOM no longer enforces the version of the org.junit-pioneer:junit-pioneer dependency. If you are using this dependency in your project, you must explicitly specify its version in your build files. To avoid any build issues, define the version in your pom.xml or build.gradle files; for example: pom.xml <properties> ... <junit-pioneer.version>2.2.0</junit-pioneer.version> ... </properties> You must apply this change manually. It is not covered by the automated update described in the Migrating applications to Red Hat build of Quarkus 3.15 guide. 1.7.8. Web 1.7.8.1. Quarkus REST: Adding web links programmatically In Red Hat build of Quarkus 3.15, for Quarkus REST (formerly RESTEasy Reactive), the signatures of the Hypertext Application Language (HAL) wrapper classes have been modified to include the type of elements in the collection: HalCollectionWrapper<T> HalEntityWrapper<T> Add the appropriate type argument wherever you use the HAL wrapper classes in your code. You must apply this change manually. It is not covered by the automated update described in the Migrating applications to Red Hat build of Quarkus 3.15 guide. New preferred method for creating HAL wrappers The preferred approach for creating HAL wrapper classes has changed. Instead of using constructors, use the helper methods provided by the io.quarkus.hal.HalService bean. For example: @Path("/records") public class RecordsResource { @Inject HalService halService; @GET @Produces({ MediaType.APPLICATION_JSON, RestMediaType.APPLICATION_HAL_JSON }) @RestLink(rel = "list") public HalCollectionWrapper<Record> getAll() { List<Record> list = // ... HalCollectionWrapper<Record> halCollection = halService.toHalCollectionWrapper( list, "collectionName", Record.class); // ... return halCollection; } @GET @Produces({ MediaType.APPLICATION_JSON, RestMediaType.APPLICATION_HAL_JSON }) @Path("/{id}") @RestLink(rel = "self") @InjectRestLinks(RestLinkType.INSTANCE) public HalEntityWrapper<Record> get(@PathParam("id") int id) { Record entity = // ... HalEntityWrapper<Record> halEntity = halService.toHalWrapper(entity); // ... return halEntity; } } Although creating HAL wrappers by using constructors still works, that approach might be deprecated in a future version. Therefore, start using the helper methods exposed by the HalService bean. For more information, see the Web Links support section of the "Quarkus REST" guide. 1.7.8.2. Quarkus REST filters on non-REST paths In earlier releases, Quarkus REST (formerly RESTEasy Reactive) filters ran even when the requested resource was not a REST resource. In Red Hat build of Quarkus 3.15, that behavior has changed. Now, Quarkus REST filters run only on REST resources. Note Quarkus REST is a Jakarta REST (formerly JAX-RS) implementation built from the ground up to work on Quarkus's common Vert.x layer. It is fully reactive and highly optimized for build-time processing. If you need your filters to apply to non-Quarkus REST resources, you can do so by adding a custom ExceptionMapper for NotFoundException , as shown in the following example: package io.quarkus.resteasy.reactive.server.test.customproviders; import jakarta.ws.rs.NotFoundException; import jakarta.ws.rs.core.Response; import jakarta.ws.rs.ext.ExceptionMapper; import jakarta.ws.rs.ext.Provider; @Provider public class NotFoundExeptionMapper implements ExceptionMapper<NotFoundException> { @Override public Response toResponse(NotFoundException exception) { return Response.status(404).build(); } } With this ExceptionMapper , Quarkus REST handles "Not Found" resources, allowing filters to run as expected. Earlier, filters always ran on non-REST resources, which made it difficult for other extensions to handle "Not Found" scenarios effectively. You must apply this change manually. It is not covered by the automated update described in the Migrating applications to Red Hat build of Quarkus 3.15 guide. 1.7.8.3. Qute REST integration update: TemplateInstance is blocking by default In Red Hat build of Quarkus 3.15, the io.quarkus.qute.TemplateInstance class is no longer registered as a non-blocking type. As a result, if a Jakarta REST (formerly JAX-RS) resource method returns a TemplateInstance object, it is now considered blocking by default. To restore the earlier non-blocking behavior, apply the @io.smallrye.common.annotation.NonBlocking annotation to the resource method. Note This change only affects applications using the Quarkus REST (formerly RESTEasy Reactive) extension, quarkus-rest . You must apply this change manually. It is not covered by the automated update described in the Migrating applications to Red Hat build of Quarkus 3.15 guide. 1.7.8.4. RESTEasy Reactive extensions renamed to Quarkus REST In Red Hat build of Quarkus 3.15, the RESTEasy Reactive extensions have been renamed to quarkus-rest-* to reflect their support for both reactive and blocking workloads. Maven relocations have been implemented. You can apply this change by running the automated update described in the Migrating applications to Red Hat build of Quarkus 3.15 guide. Replace all instances of the old extension names in your projects with the new names. Most of the new extension names follow this naming convention: Extensions ending with -rest use Quarkus REST (formerly RESTEasy Reactive). Extensions ending with -resteasy use RESTEasy Classic. Renamed extensions The following extensions have been renamed: Old Name New Name quarkus-resteasy-reactive quarkus-rest quarkus-resteasy-reactive-jackson quarkus-rest-jackson quarkus-resteasy-reactive-jaxb quarkus-rest-jaxb quarkus-resteasy-reactive-jsonb quarkus-rest-jsonb quarkus-resteasy-reactive-kotlin quarkus-rest-kotlin quarkus-resteasy-reactive-kotlin-serialization quarkus-rest-kotlin-serialization quarkus-resteasy-reactive-links quarkus-rest-links quarkus-resteasy-reactive-qute quarkus-rest-qute quarkus-resteasy-reactive-servlet quarkus-rest-servlet quarkus-rest-client-reactive quarkus-rest-client quarkus-rest-client-reactive-jackson quarkus-rest-client-jackson quarkus-rest-client-reactive-jaxb quarkus-rest-client-jaxb quarkus-rest-client-reactive-jsonb quarkus-rest-client-jsonb quarkus-rest-client-reactive-kotlin-serialization quarkus-rest-client-kotlin-serialization quarkus-jaxrs-client-reactive quarkus-rest-client-jaxrs quarkus-keycloak-admin-client quarkus-keycloak-admin-resteasy-client quarkus-keycloak-admin-client-reactive quarkus-keycloak-admin-rest-client quarkus-oidc-client-filter quarkus-resteasy-client-oidc-filter quarkus-oidc-client-reactive-filter quarkus-rest-client-oidc-filter quarkus-oidc-token-propagation quarkus-resteasy-client-oidc-token-propagation quarkus-oidc-token-propagation-reactive quarkus-rest-client-oidc-token-propagation quarkus-csrf-reactive quarkus-rest-csrf quarkus-spring-web-resteasy-classic quarkus-spring-web-resteasy quarkus-spring-web-resteasy-reactive quarkus-spring-web-rest The configuration roots have also been updated: Old configuration root New configuration root quarkus.resteasy-reactive.* quarkus.rest.* quarkus.rest-client-reactive.* quarkus.rest-client.* quarkus.oidc-client-reactive-filter.* quarkus.rest-client-oidc-filter.* quarkus.oidc-token-propagation-reactive.* quarkus.rest-client-oidc-token-propagation.* quarkus.csrf-reactive.* quarkus.rest-csrf.* quarkus.oidc-client-filter.* quarkus.resteasy-client-oidc-filter.* quarkus.oidc-token-propagation.* quarkus.resteasy-client-oidc-token-propagation.* An automatic fallback mechanism is in place to revert to the old configuration properties if necessary. Impact on extension developers If you are an extension developer, note that the following deployment-related artifacts have also been renamed: Old Name New Name quarkus-resteasy-reactive-deployment quarkus-rest-deployment quarkus-resteasy-reactive-jackson-common quarkus-rest-jackson-common quarkus-resteasy-reactive-jackson-common-deployment quarkus-rest-jackson-common-deployment quarkus-resteasy-reactive-jackson-deployment quarkus-rest-jackson-deployment quarkus-resteasy-reactive-jaxb-common quarkus-rest-jaxb-common quarkus-resteasy-reactive-jaxb-common-deployment quarkus-rest-jaxb-common-deployment quarkus-resteasy-reactive-jaxb-deployment quarkus-rest-jaxb-deployment quarkus-resteasy-reactive-jsonb-common quarkus-rest-jsonb-common quarkus-resteasy-reactive-jsonb-common-deployment quarkus-rest-jsonb-common-deployment quarkus-resteasy-reactive-jsonb-deployment quarkus-rest-jsonb-deployment quarkus-resteasy-reactive-kotlin-deployment quarkus-rest-kotlin-deployment quarkus-resteasy-reactive-kotlin-serialization-common quarkus-rest-kotlin-serialization-common quarkus-resteasy-reactive-kotlin-serialization-common-deployment quarkus-rest-kotlin-serialization-common-deployment quarkus-resteasy-reactive-kotlin-serialization-deployment quarkus-rest-kotlin-serialization-deployment quarkus-resteasy-reactive-links-deployment quarkus-rest-links-deployment quarkus-resteasy-reactive-qute-deployment quarkus-rest-qute-deployment quarkus-resteasy-reactive-server-common quarkus-rest-server-common quarkus-resteasy-reactive-server-spi-deployment quarkus-rest-server-spi-deployment quarkus-resteasy-reactive-servlet-deployment quarkus-rest-servlet-deployment quarkus-resteasy-reactive-common quarkus-rest-common quarkus-resteasy-reactive-common-deployment quarkus-rest-common-deployment quarkus-rest-client-reactive-deployment quarkus-rest-client-deployment quarkus-rest-client-reactive-jackson-deployment quarkus-rest-client-jackson-deployment quarkus-rest-client-reactive-jaxb-deployment quarkus-rest-client-jaxb-deployment quarkus-rest-client-reactive-jsonb-deployment quarkus-rest-client-jsonb-deployment quarkus-rest-client-reactive-kotlin-serialization-deployment quarkus-rest-client-kotlin-serialization-deployment quarkus-rest-client-reactive-spi-deployment quarkus-rest-client-spi-deployment quarkus-jaxrs-client-reactive-deployment quarkus-rest-client-jaxrs-deployment quarkus-keycloak-admin-client-deployment quarkus-keycloak-admin-resteasy-client-deployment quarkus-keycloak-admin-client-reactive-deployment quarkus-keycloak-admin-rest-client-deployment quarkus-oidc-client-filter-deployment quarkus-resteasy-client-oidc-filter-deployment quarkus-oidc-client-reactive-filter-deployment quarkus-rest-client-oidc-filter-deployment quarkus-oidc-token-propagation-deployment quarkus-resteasy-client-oidc-token-propagation-deployment quarkus-oidc-token-propagation-reactive-deployment quarkus-rest-client-oidc-token-propagation-deployment quarkus-csrf-reactive-deployment quarkus-rest-csrf-deployment quarkus-spring-web-resteasy-classic-deployment quarkus-spring-web-resteasy-deployment quarkus-spring-web-resteasy-reactive-deployment quarkus-spring-web-rest-deployment 1.7.8.5. WebJar Locator extension renamed to Web-dependency-locator In Red Hat build of Quarkus 3.15, the quarkus-webjars-locator extension is renamed to quarkus-web-dependency-locator and is also enhanced to include mvnpm (Maven NPM) and importmaps . Update your code and configurations to use the new extension name. You must apply this change manually. It is not covered by the automated update described in the Migrating applications to Red Hat build of Quarkus 3.15 guide. For more information, see the Quarkus Web dependency locator guide. 1.8. Known issues Review the following known issues for insights into Red Hat build of Quarkus 3.15 limitations and workarounds. 1.8.1. Missing native library for Snappy on Windows In Red Hat build of Quarkus 3.15, running an application that uses the Snappy compression library on Windows produces an error due to a missing native library. When attempting to compress data with Snappy in Windows environments, users might encounter an error message similar to the following example. Example error message ... org.eclipse.microprofile.reactive.messaging.MessageUSD5@1e8dc267 from channel 'test' was not sent to Kafka topic 'test' - nacking message: org.apache.kafka.common.KafkaException: org.xerial.snappy.SnappyError: [FAILED_TO_LOAD_NATIVE_LIBRARY] no native library is found for os.name=Windows and os.arch=x86_64 ... Workaround: No workaround is available at this time. This issue is planned to be resolved in a future release. QUARKUS-5214 1.8.2. Quarkus CLI fails to resolve Red Hat build of Quarkus TLS plugin In Red Hat build of Quarkus 3.15, productized Quarkus TLS CLI plugin was added. Currently, the development tools do not discover Quarkus CLI plugins from maven.repostory.redhat.com . As a result, the Quarkus CLI cannot locate this plugin by default. Workaround: To enable the Quarkus CLI to resolve the plugin, configure JBang to use maven.repository.redhat.com . You can do so by using a jbang.properties file with the following contents either in the project's root directory, which is used only when the Quarkus CLI is used in that project, or in the ~/.jbang directory for global configuration: If JBang is already installed, you can also set it globally with the following command: For more information, see QUARKUS-5183 and linked issues. 1.8.3. Quarkus CLI updates only the Red Hat build of Quarkus platform version In Red Hat build of Quarkus 3.15, running the update command updates only the BOMs included in the Red Hat build of Quarkus platform (com.redhat.quarkus.platform). These can include BOMs such as quarkus-camel-bom and quarkus-cxf-bom if part of the release, quarkus-qpid-jms-bom , and quarkus-operator-sdk-bom . However, the command does not update BOM versions tied to the upstream community release. If your project includes both Red Hat build of Quarkus and upstream BOMs, this issue can lead to potentially incompatible combinations of Quarkus and upstream BOMs. Example update command USD mvn com.redhat.quarkus.platform:quarkus-maven-plugin:3.15.3.SP1-redhat-00002:update -Dmaven.repo.local=<path-to-local-repo> Example pom.xml file with issue <properties> <quarkus.platform.artifact-id>quarkus-bom</quarkus.platform.artifact-id> <quarkus.platform.group-id>com.redhat.quarkus.platform</quarkus.platform.group-id> <quarkus.platform.version>3.15.3.SP1-redhat-00002</quarkus.platform.version> </properties> <dependencyManagement> <dependencies> <dependency> <groupId>USD{quarkus.platform.group-id}</groupId> <artifactId>USD{quarkus.platform.artifact-id}</artifactId> <version>USD{quarkus.platform.version}</version> </dependency> <dependency> <groupId>io.quarkus.platform</groupId> <artifactId>quarkus-amazon-services-bom</artifactId> <version>3.2.12.Final</version> 1 </dependency> </dependencies> </dependencyManagement> 1 Version not updated. Workaround: Update the version numbers manually. QUARKUS-5185 1.8.4. RSA cipher initialization triggers NPE in native mode with mandrel-for-jdk-21-rhel8:23.1 and FIPS enabled In Red Hat build of Quarkus 3.15, using the quarkus/mandrel-for-jdk-21-rhel8:23.1 Red Hat build of Quarkus Native Builder image to initialize an RSA cipher in native mode within a FIPS-enabled environment produces a NullPointerException (NPE) error. This issue occurs only in native mode with FIPS enabled; it does not affect native mode with FIPS disabled. It also does not impact JVM mode when using Red Hat build of OpenJDK with FIPS enabled. Note Native mode is not supported in a FIPS-enabled environment. Example error message Workaround: If present, remove the following property from the application.properties file: Add the following property to the application.properties file to initialize the ReproResource class at runtime: MANDREL-245 Red Hat build of Quarkus 3.15 provides increased stability and includes fixes to bugs that have a significant impact on users. To get the latest fixes for Red Hat build of Quarkus, ensure you are using the latest available version, which is 3.15.3. 1.9. Red Hat build of Quarkus 3.15.3 SP1 1.9.1. Security fixes CVE-2025-1634 io.quarkus:quarkus-resteasy : Memory leak in Quarkus RESTEasy Classic when a client requests timeout CVE-2025-24970 io.netty/netty-handler : SSLHandler does not correctly validate packets, which can lead to a native crash when using native SSLEngine CVE-2025-1247 io.quarkus/quarkus-netty : Quarkus REST endpoint request parameter leakage due to shared instance 1.9.2. Advisory Before you start using and deploying Red Hat build of Quarkus 3.15.3 SP1, review the following advisory related to the release. RHSA-2025:1885 1.10. Red Hat build of Quarkus 3.15.3 1.10.1. Bug fixes To view the issues that have been resolved for this release, see Red Hat build of Quarkus 3.15.3 bug fixes . 1.10.2. Security fixes CVE-2024-12397 io.quarkus.http/quarkus-http-core : Quarkus HTTP Cookie Smuggling CVE-2024-47535 io.quarkus/quarkus-netty : Denial of Service attack on Windows app using Netty 1.10.3. Advisory Before you start using and deploying Red Hat build of Quarkus 3.15.3, review the following advisory related to the release. RHSA-2025:0900 1.11. Advisory for Red Hat build of Quarkus 3.15.2 Red Hat build of Quarkus 3.15 provides increased stability and includes fixes to bugs that have a significant impact on users. To get the latest fixes for Red Hat build of Quarkus, ensure you are using the latest available version, which is 3.15.3. 1.11.1. Bug fixes To view the issues that have been resolved for this release, see Red Hat build of Quarkus 3.15.2 bug fixes . 1.11.2. Advisory Before you start using and deploying Red Hat build of Quarkus 3.15.2, review the following advisory related to the release. RHBA-2024:10676 1.12. Advisory for Red Hat build of Quarkus 3.15.1 Before you start using and deploying Red Hat build of Quarkus 3.15.1, review the following advisory related to the release. RHEA-2024:8930 1.13. Additional resources Migrating applications to Red Hat build of Quarkus 3.15 guide. Getting Started with Red Hat build of Quarkus Revised on 2025-02-26 19:18:47 UTC

Commands:
quarkus config encrypt --secret=<xyz123>
quarkus config encrypt <xyz123>
quarkus config set --name=<abc> --value=<xyz123>
quarkus config set <abc> <xyz123>
quarkus config remove <abc>
<dependency> <groupId>io.quarkus</groupId> <artifactId>quarkus-observability-devservices-lgtm</artifactId> <version>USD{project.version}</version> <scope>provided</scope> </dependency>
@ClientBasicAuth(username = "USD{service.username}", password = "USD{service.password}") public interface SomeClient { }
%test.quarkus.oidc.auth-server-url=USD{keycloak.url}/realms/quarkus/
%test.quarkus.oidc.auth-server-url=USD{keycloak.url:replaced-by-test-resource}/realms/quarkus/
@Inject RemoteCache<String, Book> booksCache; ... QueryFactory queryFactory = Search.getQueryFactory(booksCache); Query query = queryFactory.create("from book_sample.Book"); List<Book> list = query.execute().list();
@Inject RemoteCache<String, Book> booksCache; ... Query<Book> query = booksCache.<Book>query("from book_sample.Book"); List<Book> list = query.execute().list();
<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <configuration> <annotationProcessorPaths> <path> <groupId>io.quarkus</groupId> <artifactId>quarkus-extension-processor</artifactId> <version>USD{quarkus.version}</version> </path> </annotationProcessorPaths> <compilerArgs> <arg>-AlegacyConfigRoot=true</arg> </compilerArgs> </configuration> </plugin>
<plugin> <artifactId>maven-compiler-plugin</artifactId> <executions> <execution> <id>default-compile</id> <configuration> <annotationProcessorPaths> <path> <groupId>io.quarkus</groupId> <artifactId>quarkus-extension-processor</artifactId> <version>USD{quarkus.version}</version> </path> </annotationProcessorPaths> <compilerArgs> <arg>-AlegacyConfigRoot=true</arg> </compilerArgs> </configuration> </execution> </executions> </plugin>
<build> <plugins> <!-- other plugins --> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>3.13.0</version> <!-- Necessary for proper dependency management in annotationProcessorPaths --> <configuration> <annotationProcessorPaths> <path> <groupId>io.quarkus</groupId> <artifactId>quarkus-panache-common</artifactId> </path> </annotationProcessorPaths> </configuration> </plugin> <!-- other plugins --> </plugins> </build>
dependencies { annotationProcessor "io.quarkus:quarkus-panache-common" }
package org.acme; import org.eclipse.microprofile.reactive.messaging.Incoming; import org.eclipse.microprofile.reactive.messaging.Outgoing; @Incoming("source") @Outgoing("sink") public Result process(int payload) { return new Result(payload); }
package org.acme; import io.smallrye.common.annotation.NonBlocking; import org.eclipse.microprofile.reactive.messaging.Incoming; @Incoming("source") @NonBlocking public void consume(int payload) { // called on I/O thread }
<properties> <junit-pioneer.version>2.2.0</junit-pioneer.version> </properties>
@Path("/records") public class RecordsResource { @Inject HalService halService; @GET @Produces({ MediaType.APPLICATION_JSON, RestMediaType.APPLICATION_HAL_JSON }) @RestLink(rel = "list") public HalCollectionWrapper<Record> getAll() { List<Record> list = // HalCollectionWrapper<Record> halCollection = halService.toHalCollectionWrapper( list, "collectionName", Record.class); // return halCollection; } @GET @Produces({ MediaType.APPLICATION_JSON, RestMediaType.APPLICATION_HAL_JSON }) @Path("/{id}") @RestLink(rel = "self") @InjectRestLinks(RestLinkType.INSTANCE) public HalEntityWrapper<Record> get(@PathParam("id") int id) { Record entity = // HalEntityWrapper<Record> halEntity = halService.toHalWrapper(entity); // return halEntity; } }
package io.quarkus.resteasy.reactive.server.test.customproviders; import jakarta.ws.rs.NotFoundException; import jakarta.ws.rs.core.Response; import jakarta.ws.rs.ext.ExceptionMapper; import jakarta.ws.rs.ext.Provider; @Provider public class NotFoundExeptionMapper implements ExceptionMapper<NotFoundException> { @Override public Response toResponse(NotFoundException exception) { return Response.status(404).build(); } }
org.eclipse.microprofile.reactive.messaging.MessageUSD5@1e8dc267 from channel 'test' was not sent to Kafka topic 'test' - nacking message: org.apache.kafka.common.KafkaException: org.xerial.snappy.SnappyError: [FAILED_TO_LOAD_NATIVE_LIBRARY] no native library is found for os.name=Windows and os.arch=x86_64
run.repos=central,https://maven.repository.redhat.com/ga/
jbang config set run.repos central,https://maven.repository.redhat.com/ga/
mvn com.redhat.quarkus.platform:quarkus-maven-plugin:3.15.3.SP1-redhat-00002:update -Dmaven.repo.local=<path-to-local-repo>
<properties> <quarkus.platform.artifact-id>quarkus-bom</quarkus.platform.artifact-id> <quarkus.platform.group-id>com.redhat.quarkus.platform</quarkus.platform.group-id> <quarkus.platform.version>3.15.3.SP1-redhat-00002</quarkus.platform.version> </properties> <dependencyManagement> <dependencies> <dependency> <groupId>USD{quarkus.platform.group-id}</groupId> <artifactId>USD{quarkus.platform.artifact-id}</artifactId> <version>USD{quarkus.platform.version}</version> </dependency> <dependency> <groupId>io.quarkus.platform</groupId> <artifactId>quarkus-amazon-services-bom</artifactId> <version>3.2.12.Final</version> 1 </dependency> </dependencies> </dependencyManagement>
2024-10-17 10:45:01,931 ERROR [io.qua.ver.htt.run.QuarkusErrorHandler] (executor-thread-1) HTTP Request to /repro failed, error id: 9b1f5dbb-058b-4c9b-9377-f3acc0a6cba5-1: java.lang.RuntimeException: java.lang.NullPointerException at org.acme.ReproResource.init(ReproResource.java:38)
quarkus.security.security-providers=SunPKCS11
quarkus.native.additional-build-args=--initialize-at-run-time=org.acme.ReproResource