3.1. Cloud

3.2. Core

3.3. Data

@SearchExtension
public class AnalysisConfigurer implements ElasticsearchAnalysisConfigurer {
    @Override
    public void configure(ElasticsearchAnalysisConfigurationContext context) {
        // ...
    }
}

3.4. Logging

3.5. Messaging

3.6. Security

3.7. Web

4.1. Product updates and support lifecycle policy

In Red Hat build of Quarkus, a feature release can be either a major or a minor release that introduces new features or support. Red Hat build of Quarkus release version numbers are directly aligned with Quarkus community project release versions. The version numbering of a Red Hat build of Quarkus feature release matches the community version that it is based on.

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].

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.

4.2. Tested and verified environments

Red Hat build of Quarkus 2.13 is available on the following versions of Red Hat OpenShift Container Platform and Red Hat Enterprise Linux 8, with the listed supported installation container images.

Please note the Tested and Supported columns for each CPU architecture. To get the support status of versions in the following table whose deployment environments are not tested, see Support of Red Hat Middleware products and components on Red Hat OpenShift Container Platform in the Red Hat Knowledgebase.

• Red Hat build of Quarkus 2.13 is supported on Red Hat OpenShift Dedicated running on AMD64 and Intel 64 (x86_64) architectures. Red Hat tests Quarkus only on the latest version of OpenShift Dedicated. The same "Container image/JVM" and "Supported" values apply for OpenShift Dedicated as for OpenShift Container Platform in the preceding table.

• 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.

4.3. Development support

Red Hat provides development support for the following Red Hat build of Quarkus features, plugins, extensions, and dependencies:

5.1. Deprecation of quarkus-bootstrap-maven-plugin

The plugin, quarkus-bootstrap-maven-plugin, is deprecated in Red Hat build of Quarkus 2.13 in favor of quarkus-extension-maven-plugin, which is introduced in Quarkus 2.13.

5.2. Deprecation of quarkus-reactive-routes extension

The quarkus-reactive-routes extension is deprecated in Red Hat build of Quarkus 2.13 in favor of the Reactive Routes extension from Eclipse Vert.x. Red Hat continues to support the quarkus-reactive-routes extension in Quarkus 2.13; however, users are encouraged to use RESTEasy Reactive or the Vert.x router directly.

For more information, see the following resources:

• Quarkus Writing REST services with RESTEasy Reactive guide

• The Using the Vert.x web router section of the Quarkus "Using Reactive routes" guide

5.3. Deprecation of quarkus-resteasy-mutiny extension

The quarkus-resteasy-mutiny extension is deprecated in Red Hat build of Quarkus 2.13. You can start using the quarkus-resteasy-reactive extension instead.

5.4. Deprecation of SmallRye Metrics

Quarkus adopted Micrometer to resolve SmallRye Metrics issues during advanced use cases and offer a less intrusive way to monitor Quarkus applications.

5.5. Deprecation of SmallRye OpenTracing

SmallRye OpenTracing is now considered deprecated, and it is anticipated that this technology will be removed in a future version of Quarkus. The recommended technology for tracing and telemetry in your Quarkus applications is now OpenTelemetry.

6.1. Support for Hibernate Reactive

In Red Hat build of Quarkus 2.13, Hibernate Reactive continues to be provided as a Technology Preview feature.

Hibernate Reactive is a reactive API for Hibernate Object Relational Mapper (ORM). Hibernate Reactive supports non-blocking database drivers, which means your applications can interact with relational databases in a reactive way.

For a list of all extensions and dependencies that are available as a Technology Preview in Red Hat build of Quarkus, log in to the Red Hat Customer Portal and see the Knowledgebase solution Red Hat build of Quarkus Component Details.

7.1. AssertJ is no longer included in the Red Hat build of Quarkus BOM

To prevent compatibility issues with the AssertJ binary, from version 2.13, the AssertJ library has been removed from the Red Hat build of Quarkus BOM artifact. In previous releases, if you ran tests compiled with an older version of AssertJ, this caused problems with the version included in the Quarkus BOM.

To use the AssertJ library in your application, define the version of AssertJ in your POM manually as outlined in the following example:

<dependency>
    <groupId>org.assertj</groupId>
    <artifactId>assertj-core</artifactId>
    <version>3.22.0</version>
</dependency>

7.2. Database Dev Services use the same database name, username, and password

This update makes the database name and login credentials the same for most databases.

The PostgreSQL, MariaDB, MySQL, IBM Db2, and H2 databases use the following values:

• Database name: quarkus

• Username: quarkus for the default data source or name of the data source

• Password: quarkus

Because the Dev Service for Microsoft SQL Server does not support these changes, it uses the following values:

• Database name: none

• Username: SA

• Password: Quarkus123

You can override these values for Dev Services that support it by using the following configuration parameters or environment variables.

For more information, see the Connect To Database Run as a Dev Service section of the "Dev Services for Databases" guide.

7.3. H2 database upgraded to version 2.1

In Red Hat build of Quarkus 2.13, the in-memory H2 database is upgraded from version 1.4 to 2.1.

With this version upgrade, H2 adds new reserved keywords, such as user, value, and timestamp. If you already use these keywords in your existing column names, you must adjust your database model, for example, by changing the column name to user_, timestamp_, or value_.

Alternatively, you might need to switch to a container approach for testing and use the same database you use in production instead of an H2 database.

For more information about H2, refer to H2 database documentation.

7.4. Hibernate ORM MariaDB dialect updated to 10.6

With this update, by default, Hibernate ORM uses the MariaDB image for dialect 10.6.

If you are using MariaDB dialect 10.3, 10.4, or 10.5, override the default by setting the quarkus.hibernate-orm.dialect property in the application.properties file to quarkus.hibernate-orm.dialect=org.hibernate.dialect.MariaDB103Dialect.

For more information, see the Dialect related configuration section of the Quarkus "Using Hibernate ORM and Java Persistence API (JPA)" guide. Also, see the Package org.hibernate.dialect package summary of the "Hibernate ORM aggregated JavaDocs" documentation.

7.5. Hibernate Search quarkus.hibernate-search-orm.* configuration property changes

This update changes the behavior of the quarkus.hibernate-search-orm.enabled configuration property. Before this update, it enabled Hibernate Search at run time. With this update, it enables Hibernate Search at build time.

This update also adds the quarkus.hibernate-search-orm.active configuration property, which enables Hibernate Search at run time.

Review configuration files containing the quarkus.hibernate-search-orm.enabled property, such as ./src/main/resources/application.properties, and update them to reflect these changes.

Similarly, this update changes the behavior of the QUARKUS_HIBERNATE_SEARCH_ORM_ENABLED environment variable and adds the QUARKUS_HIBERNATE_SEARCH_ORM_ACTIVE environment variable. If needed, update any references to the QUARKUS_HIBERNATE_SEARCH_ORM_ENABLED environment variable to reflect these changes.

For more information, see the Main Configuration section of the Quarkus "Hibernate Search" guide.

7.6. HTTP compression settings are now fixed at build time

In Red Hat build of Quarkus 2.13, the behavior of HTTP compression settings is changed. With this update, HTTP compression settings are delivered at build time as configuration settings, and it is no longer possible to overwrite these settings at runtime. Specifying HTTP compression settings at build time means you can further optimize your application configuration according to your requirements.

For more information about the HTTP compression updates, see the New features, enhancements, and technical changes section and the following HTTP update, HTTP responses are compressed based on configuration property settings and media type.

7.7. Red Hat build of Quarkus does not compress all HTTP responses when quarkus.http.enable-compression=true

For RESTEasy Reactive, Reactive Routes, and static resources, an HTTP response is only compressed if the Content-Type header is set and the value is a compressed media type, as configured by using the quarkus.http.compress-media-types property.

By default, the following media types are compressed:

• text/html

• text/plain

• text/xml

• text/css

• text/javascript

• application/javascript

7.8. @InjectMock annotation might require additional qualifiers

In Red Hat build of Quarkus 2.13, the @InjectMock annotation, which is available in the quarkus-junit5-mockito extension, uses a javax.enterprise.inject.spi.BeanManager#getBeans() method internally to get the set of beans that is eligible for an @InjectMock injection point.

Before this update, due to an issue with the BeanManager#getBeans() method, if you did not specify a qualifier, any bean that matched the required type was eligible for injection. As a result, a test that injected a mock of a bean with a qualifier other than @Default and did not specify this qualifier succeeded.

With this update, you must specify a qualifier if a bean for which the mock is injected declares a qualifier other than @Default. As a result, a test fails if it injects a mock of a bean with a qualifier other than @Default but does not specify the value of this qualifier.

7.9. quarkus.datasource.devservices has been replaced with quarkus.datasource.devservices.enabled

The quarkus.datasource.devservices configuration property, which was deprecated in Red Hat build of Quarkus 2.7, is now removed.

To disable Dev Services for relational databases, use the quarkus.datasource.devservices.enabled property instead.

For more information, see the Enabling / Disabling Dev Services for Database section of the Quarkus "Dev Services for Databases" guide.

7.10. quarkus.http.allow-forwarded and quarkus.http.proxy-address-forwarding have been replaced with quarkus.http.proxy.allow-forwarded and quarkus.http.proxy.proxy-address-forwarding

The deprecated quarkus.http.allow-forwarded and quarkus.http.proxy-address-forwarding configuration properties have been removed.

To run Quarkus behind a reverse proxy, use the quarkus.http.proxy.allow-forwarded and quarkus.http.proxy.proxy-address-forwarding properties instead.

The quarkus.http.proxy configuration properties provide significantly more features than the proxy-related properties that have been removed.

For more information, see the Running behind a reverse proxy section of the Quarkus "HTTP Reference" guide.

7.11. Red Hat does not offer a Java 11-based image for Mandrel 22.3

With this update, Red Hat does not offer a Java 11-based Red Hat build of Quarkus Native builder image for Mandrel 22.3.

To compile applications into native executables, replace earlier Java 11-based images with a Java 17-based Red Hat build of Quarkus Native builder image.

The Java 17-based Red Hat build of Quarkus Native builder image is compatible with most Java 11 applications and works for most production native executable builds. However, in rare cases, it might cause build failures. One such case is when the native executable build is part of an incremental or multi-stage build process.

7.12. Request Context-related changes in SmallRye Reactive Messaging

Before this update, consuming methods of Reactive Messaging were called with an active CDI request context, which was inadvertently propagated, and was never terminated.

With this update, Quarkus corrects this behavior and ensures the request context is not activated unnecessarily on message-consuming methods. Code relying on the presence of the RequestScoped beans might need to start a request scope explicitly; for example, using @ActivateRequestContext annotation on the message-consuming method.

7.13. Removal of the quarkus-undertow-websockets extension

In Red Hat build of Quarkus 2.13, the community version of the io.quarkus:quarkus-undertow-websockets extension has been removed. Red Hat provides bug fixes and support only through the end of the Red Hat build of Quarkus 2.7 lifecycle. As an alternative to the io.quarkus:quarkus-undertow-websockets extension, you can use the WebSockets Client (io.quarkus:quarkus-websockets-client) and WebSockets Server (io.quarkus:quarkus-websockets) extensions, which are based on the WebSockets protocol implementation in Eclipse Vert.x.

For more information, see the Creating the Maven project section of the Quarkus "Using WebSockets" guide.

7.14. REST layer changes related to creating new projects

The following REST layer behavior was changed in Red Hat build of Quarkus 2.13:

• A REST layer is no longer forced on you when creating applications.

• The RESTEasy Reactive extension is not automatically added when creating new projects.

• When you create an application without extensions and with the Code examples option enabled, Quarkus now adds RESTEasy Reactive automatically to demonstrate a REST Quarkus application.

7.15. RESTEasy Reactive is the new default REST layer

When you create new applications by using Red Hat build of Quarkus, the quarkus-resteasy-reactive property is now selected by default instead of quarkus-resteasy.

RESTEasy Reactive supports both traditional blocking workloads and reactive workloads. Depending on the return types of your endpoint’s methods, RESTEasy Reactive chooses the paradigm that fits.

Example:

For more information, see the Quarkus Writing REST Services with RESTEasy Reactive guide.

7.16. SmallRye GraphQL API endpoints now act as a @Singleton bean by default

Before this update, the default scope attached to a @GraphQLApi endpoint was @Dependent. With this update, to be aligned with REST endpoints, @GraphQLApi acts as a @Singleton bean, unless you explicitly add a scope annotation to your endpoint.

7.17. SmallRye Stork extension configuration properties moved to the Quarkus namespace

In Red Hat build of Quarkus 2.13, you must now configure properties for the SmallRye Stork extension in the quarkus. namespace.

Before this update, you configured the SmallRye Stork extension by using properties with the stork.my-service prefix. With this update, you must prefix these properties with quarkus, for example, quarkus.stork.my-service.

The following example shows a sample configuration of the SmallRye Stork extension by using some of the available SmallRye Stork configuration properties:

• quarkus.stork.my-service.service-discovery.type=consul

• quarkus.stork.my-service.service-discovery.consul-host=localhost

• quarkus.stork.my-service.service-discovery.consul-port=8500

• quarkus.stork.my-service.load-balancer.type=least-response-time

• quarkus.stork.my-service.load-balancer.use-secure-random=true

For more information about SmallRye Stork and its configuration properties, see All configuration options in the Quarkus community or SmallRye Stork documentation.

7.18. Some OpenTracing libraries code moved to SmallRye OpenTracing

Relevant OpenTracing libraries code for the deprecated OpenTracing feature was migrated to the SmallRye OpenTracing repository because the code is no longer maintained by the OpenTracing community. The Java package of this code was changed, but the code remains the same.

However, the migrated code consists of private APIs and unless you are using some of these APIs, this change does not affect your applications. To avoid a breaking change, use an implemented API built on top of OpenTracing libraries.

This change affects only the applications that use non-public APIs from the opentracing-contrib library. Users who use APIs with the org.eclipse.microprofile.opentracing.Traced annotation are not affected.

7.19. Support for path-specific authentication for OIDC web-app applications added

Red Hat build of Quarkus 2.13 introduces path-based authentication for OpenID Connect (OIDC) web-app applications.

With this update, if your Quarkus application combines multiple authentication mechanisms, including the OIDC authorization code mechanism, you must specify the quarkus.http.auth.permission.<policy-name>.auth-mechanism=code property in the application.property file instead of quarkus.http.auth.permission.<policy-name>.auth-mechanism=bearer.

Before this update, such a combination of JWT bearer token and OIDC authorization code flow mechanisms was not possible.

For example, if you use the quarkus-smallrye-jwt extension to provide a JWT bearer-token authentication mechanism to authenticate requests to the /management endpoint and an OIDC authorization code flow mechanism to authenticate requests to the /web-app endpoint, set the following properties:

• quarkus.http.auth.permission.webapp.paths=/web-app

• quarkus.http.auth.permission.webapp.policy=authenticated

• quarkus.http.auth.permission.webapp.auth-mechanism=code

• quarkus.http.auth.permission.management.paths=/management

• quarkus.http.auth.permission.management.policy=authenticated

• quarkus.http.auth.permission.management.auth-mechanism=bearer

7.20. The OpenTelemetryClientFilter telemetry is not forced to be enabled for the REST Client

Before this update, a user needed to enable OpenTelemetry Tracing to create Spans for the javax.ws.rs.client.ClientBuilder.newClient() client when creating the programmatic javax.ws.rs.client.Client filter with that client.

Red Hat build of Quarkus 2.13 introduces a solution in which the user does not have to explicitly register OpenTelemetryClientFilter when creating a programmatic or injected REST client. The underlying Vert.x client used by the REST Client Reactive now adds the OpenTelemetry instrumentation and simplifies the client’s creation.

8.1. Security fixes

The following CVEs have been resolved in Red Hat build of Quarkus 2.13:

• CVE-2022-3782 keycloak: Path traversal via double URL encoding

• CVE-2023-0481 io.quarkus-quarkus-parent: quarkus: Insecure permissions on temp files

• CVE-2023-0482 RESTEasy: Creation of insecure temp files

• CVE-2023-1584 quarkus-oidc: ID and access tokens leak via the authorization code flow

• CVE-2023-28867 graphql-java: Crafted GraphQL query causes stack consumption

• CVE-2022-45787 apache-james-mime4j: Temporary File Information Disclosure in MIME4J TempFileStorageProvider

• CVE-2022-3171 protobuf-java: Timeout in parser leads to DoS

• CVE-2022-4116 quarkus_dev_ui: Dev UI Config Editor is vulnerable to drive-by localhost attacks leading to RCE

• CVE-2022-31197 postgresql: SQL Injection in ResultSet.refreshRow() with malicious column names

• CVE-2022-37734 graphql-java: DoS by malicious query

• CVE-2022-42003 jackson-databind: Deep wrapper array nesting wrt UNWRAP_SINGLE_VALUE_ARRAYS

• CVE-2022-42004 jackson-databind: Use of deeply nested arrays

• CVE-2022-42889 commons-text, apache-commons-text: Variable interpolation RCE

• CVE-2022-41946 jdbc-postgresql, postgresql-jdbc: PreparedStatement.setText(int, InputStream) Creates a temporary file if the InputStream is larger than 2k

• CVE-2023-0044 quarkus-vertx-http: A cross-site attack may be initiated, which might lead to the Information Disclosure

• CVE-2022-41881 codec-haproxy: HAProxyMessageDecoder Stack Exhaustion DoS

• CVE-2022-45047 sshd-common, mina-sshd: Java unsafe deserialization vulnerability

8.2. Other enhancements and bug fixes

9.1. Using CDI interceptors to resolve multitenant OIDC configuration fails due to security fix in version 2.13.9.SP1

This breaking change is relevant only when using multiple OIDC providers with RestEasy Classic and occurs if you use Context and Dependency Injection (CDI) interceptors to programmatically resolve OIDC tenant configuration identifiers.

Before this fix, CDI interceptors ran before authentication checks. After introducing the fix, authentication occurs before CDI interceptors are triggered. Therefore, using CDI interceptors to resolve multiple OIDC provider configuration identifiers no longer works. RestEasy Reactive applications are not affected.

For more information, see the Resolving tenant identifiers with annotations section of the Quarkus “Using OpenID Connect (OIDC) multitenancy” guide.

9.2. Red Hat build of Quarkus 2.13.9 does not support domain sockets

Red Hat build of Quarkus 2.13.x and 3.2 do not support native transport and associated features. Thus, the use of the native epoll or io_uring transports and the use of domain sockets, which require native transport, are also not supported.

9.3. HTTP security bypass issue when using path-based rules to protect HTTP endpoints

Before Red Hat build of Quarkus version 2.13.8.SP2, a security issue CVE-2023-4853 exists whereby an attacker could potentially bypass the security policy altogether, resulting in unauthorized endpoint access and possibly a denial of service.

If you have secured the HTTP endpoints of your Quarkus applications by using path-based rules, you must ensure that your Quarkus applications are updated to Red Hat build of Quarkus 2.13.8.SP2. Alternatively, follow the workaround options provided by the Red Hat Product Security Center.

For more information about this security issue and for detailed instructions about the different mitigation options, see the Mitigation section of the Red Hat Security Bulletin RHSB-2023-002.

9.4. User experience side-effect with CORS filter

quarkus.http.cors=true
quarkus.http.cors.origins=https://my.org

Configuring the Vert.x HTTP CORS filter to allow the same host origins is now required due to a side-effect of fixing CVE-2022-4147 quarkus-vertx-http: Security misconfiguration of CORS : OWASP A05_2021 level in Quarkus.

Red Hat is evaluating whether to relax this requirement in a future release of Red Hat build of Quarkus.

10.1. Red Hat build of Quarkus 2.13.9.SP1

• RHSA-2024:0494

10.2. Red Hat build of Quarkus 2.13.9

• RHSA-2023:7700

10.3. Red Hat build of Quarkus 2.13.8.SP3

• RHSA-2023:5724

10.4. Red Hat build of Quarkus 2.13.8.SP2

• RHSB-2023-002

10.5. Red Hat build of Quarkus 2.13.8

• RHEA-2022:8505

• RHSA-2022:9023

• RHBA-2023:0176

• RHBA-2023:0711

• RHSA-2023:0758

• RHEA-2023:1144

• RHBA-2023:1339

• RHBA-2023:1477

• RHBA-2023:3685

• RHSA-2023:3809