Release Notes for Red Hat build of Quarkus 3.20

In Red Hat build of Quarkus 3.20, the following extensions upgrade the Fabric8 Kubernetes Client from version 6.13 to 7.1.

This upgrade brings several improvements to performance, compatibility, and testing.

Some key benefits of Fabric8 Kubernetes Client 7.1:

This change introduces breaking changes. For details, see this release note in the "Changes that affect compatibility with earlier versions" section.

This change requires manual intervention. It is not included in the automated update process described in the Migrating applications to Red Hat build of Quarkus 3.20 guide.

Starting in Red Hat build of Quarkus 3.20, Red Hat builder and runtime base images use Red Hat Universal Base Image 9 (UBI 9) by default.

The following images are upgraded:

This upgrade introduces breaking changes. Builder and runtime base images upgraded to UBI 9.

To upgrade to UBI 9 images manually, the following table outlines your options:

If you encounter issues with UBI 9-based runtime images, you can manually switch back to UBI 8-based images. For details, see Builder and runtime base images upgraded to UBI 9.

For more information, see the following resources:

With Red Hat build of Quarkus 3.20, extensions can now declare conditional dependencies that are activated only in development mode (dev mode) or when specific conditions are met, avoiding unnecessary dependencies in normal and test modes.

For more information, see the Dev mode-only extension dependencies section of the Quarkus "Conditional extension dependencies" guide.

Red Hat build of Quarkus 3.20 updates locale handling to align with Mandrel version 24.2 and later.

Applications now use a consistent default locale at run time, independent of the build system’s locale. This change improves portability and predictability of locale-sensitive behavior across environments.

This change introduces breaking changes. For details, see this release note in the "Changes that affect compatibility with earlier versions" section.

This change requires manual intervention. It is not included in the automated update process described in the Migrating applications to Red Hat build of Quarkus 3.20 guide.

Starting in Red Hat build of Quarkus 3.20, the quarkus-agroal extension adds a dedicated Agroal - Database connection pool card and page for monitoring database connections to the Dev UI.

If your Quarkus application includes a JDBC driver extension that uses the quarkus-agroal extension, it is automatically included in your application.

In the Dev UI, you can favorite (star) the Agroal - Database connection pool card. You can also drag the Database view link from the card to the Dev UI menu. Clicking Database view opens the Agroal - Database connection pool page, where you can view all active datasources, including connection URLs.

This enhancement streamlines database monitoring and configuration within the Dev UI, improving debugging and database management.

In Red Hat build of Quarkus 3.20, the quarkus-datasource extension now validates datasource configurations during application startup by using the ArC-optimized dependency injection framework. This enhancement ensures that misconfigurations are detected early, preventing runtime failures and reducing the risk of traffic being routed to faulty instances.

Key changes in Red Hat build of Quarkus:

For more information, see the Activate or deactivate datasources section of the "Configure data sources" guide.

Red Hat build of Quarkus 3.20 introduces the quarkus-messaging-kafka extension, which adds support for Apache Kafka transactions through the SmallRye Reactive Messaging Kafka connector. This feature enables atomic writes to multiple Kafka topics and partitions, ensuring that either all records within a transaction are committed or none are, enhancing data consistency in event-driven applications.​

This functionality is available as a Technology Preview feature.

For more information, see the Kafka Transactions section of the Quarkus "Apache Kafka Reference Guide" guide.

Starting in Red Hat build of Quarkus 3.20, extension developers can create a custom log tab in the Dev UI footer and stream log data to it. This process is similar to creating a card or page in the Dev UI.

Log tabs provide continuous data for application developers to monitor and troubleshoot their applications without switching tools. Unlike pages, which disconnect from the back end when navigated away from, log tabs remain persistently connected.

For more information, see the Add a footer tab section of the Quarkus "Dev UI for extension developers" guide.

Red Hat build of Quarkus 3.20 provides multiple pre-configured Grafana dashboards when using LGTM Dev Services. These dashboards visualize application metrics, traces, and logs. They leverage OpenTelemetry for seamless data collection and presentation. Some dashboards display Micrometer data in multiple ways, including OpenTelemetry output. Each dashboard is tuned for a specific application setup.

The available dashboards are:

Some dashboard panels may take a few minutes to display accurate data due to calculations over a sliding time window.

Since this update, you can now exclude specific URIs from OpenTelemetry tracing using the quarkus.otel.traces.suppress-application-uris configuration property. This allows you to define a comma-separated list of URI patterns that the tracer should ignore.

For example, setting quarkus.otel.traces.suppress-application-uris=trace,ping,people* will turn off tracing for the /trace and /ping URIs, as well as any URI starting with /people, such as /people/1 or /people/1/cars.

If you use a custom quarkus.http.root-path, ensure you include it in the configuration.

In Red Hat build of Quarkus 3.20, the quarkus-opentelemetry extension adds support for the SimpleSpanProcessor, which immediately exports spans and logs as they finish. This behavior is particularly useful in serverless environments and short-lived applications.

To enable this feature, set the following configuration property to true:

quarkus.otel.simple=true

This configuration replaces the default BatchSpanProcessor, ensuring spans and logs are sent immediately instead of being buffered. This change is critical for Lambda functions and other short-lived processes because it ensures that telemetry data is exported before the application shuts down, preventing data loss caused by batching delays.

In Red Hat build of Quarkus 3.20, the quarkus-opentelemetry extension now supports OpenTelemetry (OTel) logging. You can use this capability to provide distributed logging for interactive web applications.

To enable this feature, set the following configuration property to true:

quarkus.otel.logs.enabled=true

For more information, see the Quarkus Using OpenTelemetry Logging guide.

In Red Hat build of Quarkus 3.20, the quarkus-opentelemetry extension offers automatic instrumentation for JVM and HTTP server request metrics in alignment with the MicroProfile Telemetry 2.0 specification, provided that OpenTelemetry metrics are enabled.

OpenTelemetry metrics are disabled by default. To collect JVM and HTTP server request metrics, you must enable them by setting quarkus.otel.metrics.enabled=true.

The corresponding configuration properties are enabled by default and can be disabled by setting quarkus.otel.instrument.jvm-metrics=false or quarkus.otel.instrument.http-server-metrics=false in your configuration.

The Fault Tolerance with OpenTelemetry Metrics integration feature remains currently unsupported.

Red Hat build of Quarkus 3.20 adds support for using multiple authentication mechanisms within a single request. You can now combine mechanisms such as mutual TLS (mTLS) and OpenID Connect (OIDC) bearer token authentication in the same authentication flow.

By default, authentication completes when the first SecurityIdentity is produced by one of the registered authentication mechanisms. To require all mechanisms to validate credentials, enable inclusive authentication by setting a configuration property.

This capability is beneficial when combining mutual TLS and bearer token authentication, such as in scenarios that require access token binding to a client certificate.

For more information and examples, see the Combining authentication mechanisms section of the "Security architecture" guide.

Red Hat build of Quarkus 3.20 adds support for using @PermissionsAllowed within meta-annotations so that you can create custom security annotations for more streamlined access control management.

This enhancement simplifies permission-based configuration, reduces repetitive security code, and improves maintainability. You can now define reusable security annotations that encapsulate @PermissionsAllowed, making permission handling more efficient and consistent.

For more information and examples, see the Create permission meta-annotations section of the "Authorization of web endpoints" guide.

Starting in Red Hat build of Quarkus 3.20, you can use the @PermissionChecker annotation to define declarative permission checkers in CDI bean methods. This enhancement enables flexible and reusable authorization logic by allowing permission checks to be implemented separately from resource classes, reducing code duplication and improving maintainability.

These permission checkers work alongside @PermissionsAllowed by matching permission names based on string equality. They support general-purpose authorization checks by evaluating the SecurityIdentity, which represents the authenticated user, and the incoming HTTP request parameters. This approach allows for fine-grained access control. Checkers must be defined in normal-scoped or singleton CDI beans and return either a boolean or Uni<Boolean>, supporting both synchronous and reactive authorization checks.

This feature simplifies permission management by centralizing authorization logic, making security policies easier to enforce across multiple endpoints. Developers can create generalized permission checkers that validate multiple actions dynamically.

For more information, see the Create permission checkers section of the "Authorization of web endpoints" guide.

Starting in Red Hat build of Quarkus 3.20, with quarkus-oidc, you can configure OIDC to authenticate an OIDC provider client by loading a JWT bearer token from a filesystem.

This approach enables secure and automated authentication. It is especially useful in containerized environments such as OpenShift, where a service account token can be mounted as a file. Red Hat build of Quarkus automatically loads the token from the file and reloads it when the token expires.

For configuration details and usage examples, see the following resources:

In Red Hat build of Quarkus 3.20, the following Quarkus extensions introduce OpenID Connect (OIDC) response filters.

Implement OidcResponseFilter to inspect response status, headers, and body, for logging or other actions.

By default, OIDC response filters apply globally. To target specific endpoints, such as the token endpoint, use the @OidcEndpoint annotation.

For more information, see the OIDC response filters section of the "OpenID Connect (OIDC) authentication" guide.

Mutual TLS (mTLS) token binding enhances security by ensuring that access tokens are cryptographically bound to the client’s mTLS authentication certificate.

This feature, based on RFC 8705, minimizes the risk of accepting stolen bearer access tokens by verifying that a thumbprint of the certificate used for authentication matches a certificate thumbprint contained in the token.

Starting in Red Hat build of Quarkus 3.20, the Quarkus OIDC extension, quarkus-oidc, now supports certificate-bound access tokens for endpoints secured with both OpenID Connect (OIDC) and mTLS.

To enable this feature, set the following configuration property:

quarkus.oidc.token.binding.certificate=true

For more information, see the Mutual TLS token binding section of the "OpenID Connect (OIDC) authentication" guide.

Red Hat build of Quarkus 3.20 introduces support for injecting OidcProviderClient, allowing applications to interact with the OpenID Connect (OIDC) provider’s UserInfo, token introspection, and revocation endpoints.

It enables developers to access UserInfo, token introspection, and revocation endpoints programmatically when needed. For example, an access token can be revoked after a user logs out.

For more information, see the Token revocation section of the OpenID Connect (OIDC) authentication guide.

Starting in Red Hat build of Quarkus 3.20, with quarkus-oidc you can programmatically define OpenID Connect (OIDC) tenants by using the OidcTenantConfig builder instead of configuring them in the application.properties file.

This approach provides greater flexibility than defining OIDC tenants in the configuration.

This approach is particularly useful for features that require static tenants, such as issuer-based and path-based tenant resolvers.

For more information, see the following resources in the "OpenID Connect (OIDC) authentication" guide:

In Red Hat build of Quarkus 3.20, Dev Services for Keycloak can now start even when the quarkus-oidc extension is not present. This change enables you to test the quarkus-oidc-client extension in isolation, without requiring the full OIDC extension.

Additionally, Red Hat build of Quarkus now automatically configures key OIDC Client properties when Dev Services for Keycloak is enabled, including:

Previously, you had to set these properties manually.

These enhancements are backward compatible. Existing workflows and manual configurations continue to work as expected.

Red Hat build of Quarkus 3.20 now supports configuring policies for handling expired or not-yet-valid certificates during TLS handshakes across the certificate chain.

Previously, the trust store allowed such certificates without warnings, adhering to RFC 3280 and related specifications.

With this update, users can control the behavior by selecting one of the following options:

In Red Hat build of Quarkus 3.20, the quarkus-oidc extension now supports Demonstrating Proof of Possession (DPoP) for access tokens.

This functionality is available as a Technology Preview feature.

For more information, see the following resources:

In Red Hat build of Quarkus 3.20, the quarkus-tls-registry extension introduces support for encrypted PKCS#8 private keys in PEM keystores.

This functionality is available as a Technology Preview feature.

It enables developers to secure private keys with AES-128-CBC encryption, improving application security.

To use this feature, set the quarkus.tls.key-store.pem.password property with the keystore password.

For more information, see the Management of security keys and certificates with the TLS Registry guide.

With Red Hat build of Quarkus 3.20, extension authors can define JVM options for applications running in development mode. They can specify these options, such as --enable-preview or --add-opens, directly in the extension metadata, eliminating the need for them to be configured by application developers.

Extensions automatically apply these JVM options when running in development mode, ensuring a consistent environment for all application developers.

Application developers can turn off all extension-provided JVM options or selectively turn off options for specific extensions with the Quarkus Maven plugin. For more information, see the Extension provided Dev mode Java options section of the Quarkus "Quarkus and Maven" guide.

Starting in Red Hat build of Quarkus 3.20, the Dev UI footer includes an HTTP tab, which you can use to monitor incoming HTTP access log messages without switching tools or contexts.

For example, if you interact with your application’s HTTP endpoints by using the SmallRye OpenAPI - Swagger UI page in the Dev UI, you can see the corresponding log messages in the HTTP tab in the Dev UI footer.

For more information, see the Configuring HTTP access logs section of the Quarkus "HTTP reference" guide.

Red Hat build of Quarkus 3.20 introduces support for Java records as REST endpoint parameter containers, enabling concise and immutable data structures. Records can encapsulate queries, cookies, headers, forms, or multipart parameters, simplifying data handling in RESTful services.

Java records already work for JSON serialization and deserialization of REST bodies. However, @BeanParam does not yet support them because of the limitations of the Jakarta REST specification.

In Red Hat build of Quarkus 3.20, the quarkus-rest and quarkus-resteasy extensions add support for the new @AuthorizationPolicy annotation. You can use this annotation to bind a named HttpSecurityPolicy directly to a Jakarta REST endpoint. This feature provides an alternative to path-matching rules and enables more flexible authorization checks without modifying SecurityIdentity roles.

For more information, see the Custom HttpSecurityPolicy section of the "Authorization of web endpoints" guide.

In Red Hat build of Quarkus 3.20, the quarkus-rest-client extension adds support for the @Url annotation. You can now annotate a parameter in a REST client method to provide a URL at run time dynamically.

Typically, a REST client requires a base URL that is configured globally. However, some cases require setting the URL on a per-invocation basis. The @Url annotation supports this use case by enabling dynamic URL resolution for individual calls.

For more information, see the Dynamic base URLs section of the Quarkus "Using the REST Client" guide.

In Red Hat build of Quarkus 3.20, the quarkus-rest-client extension has been updated to MicroProfile REST Client 4.0. This update enhances how applications interact with RESTful services by providing a standardized, declarative API for creating and managing REST clients. It improves flexibility, performance, and security, while simplifying the integration of external REST services.

In Red Hat build of Quarkus 3.20, the quarkus-rest-jackson extension enhances its JSON processing capabilities by introducing reflection-free deserialization.

This enhancement complements reflection-free serialization, which was implemented in an earlier release.

By default, reflection-free JSON processing is disabled. To enable it, set the following configuration property to true:

quarkus.rest.jackson.optimization.enable-reflection-free-serializers=true

By eliminating reliance on reflection during deserialization, applications can achieve better performance and reduced memory consumption, particularly for native applications where reflection can introduce overhead. If you enable this feature, run tests to assess its effect on your applications.

For more information, see the JSON serialisation section of the Quarkus "Writing REST services with Quarkus REST" guide.

Red Hat build of Quarkus 3.20 introduces support for the quarkus-websockets-next extension, which provides a modern, declarative API for defining WebSocket server and client endpoints.

This extension enables efficient, scalable real-time communication and integrates with Red Hat build of Quarkus’s reactive architecture and networking layer.

Unlike the deprecated quarkus-websockets extension, WebSockets Next does not implement the Jakarta WebSocket specification.

Key capabilities introduced by WebSockets Next:

For details, see the Security section of the “WebSockets Next reference” guide.

For more information, see the Serialization and deserialization section.

For configuration details, see the Telemetry section of the WebSockets Next reference guide.

For more information, see the following resources:

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.

In Red Hat build of Quarkus 3.20, the following extensions upgrade the Fabric8 Kubernetes Client from version 6.13 to 7.1.

Although the quarkus-openshift and quarkus-kubernetes extensions use Fabric8, their functionality remains unchanged, so you do not need to make any updates for them.

The io.quarkus:quarkus-test-openshift-client module has been removed as part of this upgrade. If your tests use this module, migrate to io.quarkus:quarkus-test-kubernetes-client, which offers equivalent functionality. For more information, see the OpenShift client section of the Quarkus "Kubernetes Client" guide.

The upgraded Fabric8 Kubernetes Client reorganized some model types and classes, moving some to different modules. To find their new locations, refer to the official Fabric8 Kubernetes Client: Migration from 6.x to 7.x guide.

Review your application for any affected dependencies, configurations, or API usages, and update them as needed. Then, thoroughly test your application to ensure full compatibility with Fabric8 7.1.

This change requires manual intervention. It is not included in the automated update process described in the Migrating applications to Red Hat build of Quarkus 3.20 guide.

In Red Hat build of Quarkus 3.15, many extensions and configuration properties were renamed as part of the rebranding of RESTEasy Reactive to Quarkus REST and Reactive Messaging to Quarkus Messaging. To support this transition, artifact relocations and configuration fallbacks were introduced.

In Red Hat build of Quarkus 3.20, these artifact relocations and configuration fallbacks have been removed. You must now use the new artifact names and configuration properties.

For more additional background information, see the RESTEasy Reactive extensions renamed to Quarkus REST section of the "Release Notes for Red Hat build of Quarkus 3.15" guide.

Red Hat build of Quarkus 3.20 updates locale handling to align with Mandrel version 24.2 and later.

To ensure consistent locale behavior across all applications, Red Hat build of Quarkus applies a standardized default locale strategy. Use the following table to determine how your application’s behavior changes based on your locale configuration.

The en_US locale is always embedded in the native executable, regardless of the quarkus.locales configuration.

Review your application’s locale settings in the configuration properties and, if necessary, update the settings to avoid unexpected changes in behavior.

This change requires manual intervention. It is not included in the automated update process described in the Migrating applications to Red Hat build of Quarkus 3.20 guide.

In Red Hat build of Quarkus 3.20, the configuration properties for @Fallback.fallbackMethod() and @BeforeRetry.methodName() are now resolved at build time and cannot be changed at runtime. The affected configuration properties are:

This change ensures proper reflection configuration and compatibility with native image compilation.

In Red Hat build of Quarkus 3.20, the quarkus-smallrye-fault-tolerance extension includes SmallRye Fault Tolerance 6.7.0, which introduces no breaking changes but includes the following updates:

For more information, see the SmallRye Fault Tolerance 6.7.0 release announcement, which includes links to the migration guides for the programmatic API and details about the new configuration properties. The Quarkus SmallRye Fault Tolerance guide provides a complete reference for these configuration properties.

Starting in Red Hat build of Quarkus 3.20, the behavior of methods in io.quarkus.scheduler.Scheduler has changed.

When the scheduler is not started, almost all methods now throw an UnsupportedOperationException.

To verify whether the scheduler is running, you can use a new method, Scheduler#isStarted().

This change affects scheduler instances coming from both the quarkus-scheduler and quarkus-quartz extensions.

Starting in Red Hat build of Quarkus 3.20, when you use development and test modes, the management interface listens on the localhost interface by default instead of on 0.0.0.0. This change aligns with the behavior of the main interface.

On Windows with Windows Subsystem for Linux (WSL), both the management and main interfaces continue to listen on 0.0.0.0.

For more information, see the Quarkus Management interface reference guide.

In Red Hat build of Quarkus 3.20, configuration has migrated to the @ConfigMapping framework. This change deprecates the legacy configuration classes in favor of a unified configuration model based on interfaces and method signatures.

A compatibility layer remains in place for certain commonly used configuration classes, but it is planned for removal in a future release.

Starting in Red Hat build of Quarkus 3.20, Red Hat builder and runtime base images are upgraded to use Red Hat Universal Base Image 9 (UBI 9).

When upgrading from UBI 8 to UBI 9, be aware that changes in system dependencies, native image builds, or package and GNU C Library (glibc) version updates might affect your application’s behavior or runtime environment. Review and update your configurations as needed.

If you encounter issues with UBI 9, you can manually switch back to using UBI 8:

For more information, see the following resources:

In earlier versions of Red Hat build of Quarkus, when Dev Services were disabled or running in production mode, the quarkus.datasource.reactive.url and quarkus.datasource.<datasource-name>.reactive.url properties were implicitly set to an undocumented default, targeting localhost with a database-specific port.

Starting in Red Hat build of Quarkus 3.20, these properties no longer have a default value when Dev Services are disabled or the application is running in production mode. If the property is not set, the corresponding datasource is deactivated. If the application attempts to use a deactivated datasource, it will fail at startup. For details, see the Datasource usage fails fast if datasource is deactivated or has no URL set release note.

If your application requires an active datasource and you want it to connect to a database on localhost, you must now set the quarkus.datasource.reactive.url or quarkus.datasource.<datasource-name>.reactive.url property explicitly. For example:

quarkus.datasource.reactive.url=postgresql://localhost:5432/mydatabase

In earlier versions, this configuration was set implicitly. Starting with this release, you must define the URL to activate the datasource.

Previously, when Dev Services were disabled or in production mode, Red Hat build of Quarkus contributed a health check for datasources even if quarkus.datasource.jdbc.url, quarkus.datasource.<datasource-name>.jdbc.url, quarkus.datasource.reactive.url, or quarkus.datasource.<datasource-name>.reactive.url properties were not set. This caused unreliable health checks that always succeeded for JDBC datasources and almost always failed for reactive datasources.

Starting with Red Hat build of Quarkus 3.20, datasources without a URL no longer contribute a health check. To ensure a health check is available, explicitly set the quarkus.datasource.jdbc.url, quarkus.datasource.<datasource-name>.jdbc.url, quarkus.datasource.reactive.url, or quarkus.datasource.<datasource-name>.reactive.url property.

In Red Hat build of Quarkus 3.20, applications start successfully even if a datasource is deactivated with quarkus.datasource.active=false or lacks a URL. This behavior often leads to runtime failures when the datasource is first accessed, especially when Dev Services are disabled or in production mode.

With this update, applications fail to start if Red Hat build of Quarkus detects that a datasource is used but is either deactivated or missing a URL.

Red Hat build of Quarkus now enforces stricter validation during startup to catch these issues early:

The same validation applies to the Flyway and Liquibase extensions for their Flyway and LiquibaseFactory CDI beans.

In Red Hat build of Quarkus 3.20, the quarkus-flyway extension upgrades Flyway to version 11, which removes the cleanOnValidationError configuration parameter. Additionally, calling Flyway.validate() no longer cleans on validation error.

To mitigate this change, Red Hat build of Quarkus 3.20 introduces the quarkus.flyway.validate-at-start.clean-on-validation-error configuration property, which provides behavior similar to cleanOnValidationError, but applies only when the application starts.

Workaround: If you require the previous behavior of cleanOnValidationError in explicit calls to Flyway.validate(), consider catching validation errors in your application and triggering a database cleanup explicitly using Flyway.clean().

This change requires manual intervention. It is not included in the automated update process described in the Migrating applications to Red Hat build of Quarkus 3.20 guide.

For more information, see the Quarkus Using Flyway guide.

In Red Hat build of Quarkus 3.20, the IBM Db2 driver and container image that Dev Services uses have been upgraded to version 12.

The automated update described in the Migrating applications to Red Hat build of Quarkus 3.20 guide upgrades the IBM Db2 driver and container image to version 12.

Review the new license requirements, configuration steps, and SSL/TLS settings detailed on IBM’s Features with behavior changes when upgrading to the Db2 Connect 12.1 driver for upgrading to Db2 Connect 12.1.

This change requires manual intervention. It is not included in the automated update process described in the Migrating applications to Red Hat build of Quarkus 3.20 guide.

In Red Hat build of Quarkus 3.20, the default behavior of Hibernate ORM’s Bean Validation integration has changed. Previously, validation constraints were not considered during Data Definition Language (DDL) generation. With this release, Hibernate ORM includes applicable validation constraints in DDL by default, ensuring that database schemas align more closely with application-level constraints.

The quarkus.hibernate-orm.validation.enabled property has also been deprecated.

For more information about these changes and guidance on migrating your application, see the Migration Guide 3.19, or the following resources:

In Red Hat build of Quarkus 3.20, the quarkus.log.*.json configuration property has been deprecated. To enable JSON formatting for logging, use the quarkus.log.*.json.enabled property instead.

This change was introduced to improve compatibility with YAML configuration, where the previous structure required using special syntax such as ~ to assign a value to the root key, leading to confusing or error-prone setups.

For more information, see the Migration Guide 3.19.

In Red Hat build of Quarkus 3.20, the quarkus-opentelemetry extension introduces breaking changes because some database incubating values, such as those related to Redis, were moved to a different package.

OpenTelemetry does not maintain a list of changes for database semantic conventions because they are not yet stable.

This change might require manual intervention, if you use manual instrumentation. It is not included in the automated update process described in the Migrating applications to Red Hat build of Quarkus 3.20 guide.

In Red Hat build of Quarkus 3.20, the previously deprecated quarkus-smallrye-opentracing extension and related configuration property quarkus.datasource.jdbc.tracing have been removed.

The quarkus-opentelemetry extension is now the preferred tracing solution. To enable JDBC tracing with OpenTelemetry, use the following configuration property:

quarkus.datasource.jdbc.telemetry=true

To migrate, replace the OpenTracing extension with OpenTelemetry and update your configuration accordingly.

Starting in Red Hat build of Quarkus 3.20, if you use the quarkus-oidc-client extension but do not configure the OpenID Connect (OIDC) client to point to a specific URL, Dev Services for Keycloak automatically starts in dev mode.

To disable this behavior, add the following property to your application.properties file:

quarkus.keycloak.devservices.enabled=false

In Red Hat build of Quarkus 3.20, the quarkus-security-webauthn extension has been reimplemented by using WebAuthn4J to enhance security, align with industry standards, and improve long-term maintainability.

As a result, this update is not compatible with previous versions of the extension.

To transition smoothly to the new implementation, use the following information.

The status of this feature is downgraded from preview to experimental to allow for further stabilization.

For more information, see the Quarkus Using Security with WebAuthn guide.

This change requires manual intervention. It is not included in the automated update process described in the Migrating applications to Red Hat build of Quarkus 3.20 guide.

Earlier, Red Hat build of Quarkus 3.15 shipped with a version of @WithTestResource that was flawed and was thus not announced.

In Red Hat build of Quarkus 3.20, the flaws have been fixed, resulting in a breaking change. In this release, the earlier restrictToAnnotatedClass field has been replaced by scope.

In earlier releases, the quarkus-junit5-mockito dependency was configured to create mock objects by using the subclass mocking strategy.

Starting in Red Hat build of Quarkus 3.20, the dependency is now configured to use an inline mocking strategy by default.

If HTTP compression is enabled, the quarkus.http.compress-media-types configuration property defines the list of media types to compress. In Red Hat build of Quarkus 3.20, the default value of this property has changed. Newly compressed media types now include application/json and application/xhtml+xml.

In Red Hat build of Quarkus 3.20, the REST Client Configuration became more strict to reduce the number of lookups and combinations required to retrieve the configuration:

Starting in Red Hat build of Quarkus 3.20, the quarkus-qute extension automatically escapes double quotes ("), backslashes (\), and control characters (U+0000 through U+001F) in JSON templates if a corresponding template variant is set. The extension automatically assigns a variant to templates located in the src/main/resources/templates directory.

By default, java.net.URLConnection#getFileNameMap() determines the content type of a template file. You can define additional suffix-to-content-type mappings by using the quarkus.qute.content-types configuration.

To render the unescaped value, use the raw or safe properties, which are implemented as extension methods of java.lang.Object, or wrap the string value in the io.quarkus.qute.RawString class.

For more information, see the Character escapes section of the Quarkus "Qute reference" guide.

In Red Hat build of Quarkus 3.20, with the quarkus-rest-jackson extension, only ObjectMapperCustomizer beans without qualifiers are applied to the default ObjectMapper instance of the Jackson JSON processor.

In earlier versions, all customizer beans, including those with custom qualifiers, were applied to the default ObjectMapper instance.

This change requires manual intervention. It is not included in the automated update process described in the Migrating applications to Red Hat build of Quarkus 3.20 guide.

For more information, see the following resources:

In earlier releases, with the quarkus-rest extension, query parameters with empty values, such as ?foo=, were deserialized as follows:

In Red Hat build of Quarkus 3.20, this behavior has changed:

Update your code accordingly.

This change requires manual intervention. It is not included in the automated update process described in the Migrating applications to Red Hat build of Quarkus 3.20 guide.

Red Hat build of Quarkus 3.20 deprecates the quarkus-websockets and quarkus-websockets-client extensions, which implement the Jakarta WebSocket specification.

Red Hat build of Quarkus plans to stop supporting these extensions in a future release.

To ensure compatibility with upcoming versions, migrate to the Quarkus WebSockets Next extension,quarkus-websockets-next, which offers a modern, more efficient WebSocket API.

For more information, see the following Quarkus resources:

This change requires manual intervention. It is not included in the automated update process described in the Migrating applications to Red Hat build of Quarkus 3.20 guide.