Release Notes for Red Hat build of Quarkus 2.2

Guide

Red Hat build of Quarkus 2.2

Updated 02 March 2022
Published 20 October 2021

These release notes list new features, features in technology preview, known issues, and issues fixed in Red Hat build of Quarkus 2.2.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. Because of the enormity of this endeavor, these changes will be implemented gradually over several upcoming releases. For more details, see our CTO Chris Wright’s message.

1. Red Hat build of Quarkus

Red Hat build of Quarkus is a Kubernetes-native Java stack that is optimized for use with containers and Red Hat OpenShift Container Platform. Quarkus is designed to work with popular Java standards, frameworks, and libraries such as Eclipse MicroProfile, Apache Kafka, RESTEasy (JAX-RS), Hibernate ORM (JPA), Spring, Infinispan, and Apache Camel.

The Quarkus dependency injection solution is based on CDI (contexts and dependency injection) and includes an extension framework to expand functionality and to configure, boot, and integrate a framework into your application. Dependency injection in the Red Hat build of Quarkus is based on Quarkus ArC, a CDI-based build-time-oriented dependency injection solution for Quarkus architecture. ArC is a transitive quarkus-resteasy dependency, and as such, it is already present in your project.

Quarkus provides a container-first approach to building Java applications. This approach makes it much easier to build microservices-based applications written in Java as well as enabling those applications to invoke functions running on serverless computing frameworks. For this reason, Quarkus applications have small memory footprints and fast startup times.

2. Quarkus metering labels for Red Hat OpenShift

You can add metering labels to your Quarkus pods and check Red Hat subscription details with the OpenShift Metering Operator.

Do not add metering labels to any pods that an operator or a template deploys and manages.
You can apply labels to pods using the Metering Operator on OpenShift Container Platform version 4.8 and earlier. From version 4.9 onward, the Metering Operator is no longer available without a direct replacement.

Quarkus can use the following metering labels:

com.company: Red_Hat
rht.prod_name: Red_Hat_Runtimes
rht.prod_ver: YYYY-Q1
rht.comp: "Quarkus"
rht.comp_ver: 2.2.5
rht.subcomp: {sub-component-name}
rht.subcomp_t: application

Additional resources

Configuring and using Metering in OpenShift Container Platform

3. New and changed features

This section provides an overview of new features and changes to previously available features that are introduced in Red Hat build of Quarkus 2.2.

3.1. Support for Java 17 in JVM mode

Red Hat build of Quarkus version 2.2.5 introduces support for Java version 17. Java 17 is supported in JVM mode only. If you are building a Quarkus native executable, Java 17 is not supported, and you must continue to use Java version 11.

If you are deploying a Java 17 Quarkus application in JVM mode to OpenShift, some additional JDK configuration is required. For more information, see Deploying your Quarkus applications to OpenShift.

For more information about the Java and OpenJDK versions, see Red Hat build of Quarkus Supported Configurations (login required).

3.2. Product release of the Quarkus Maven Plugin

Quarkus 2.2 includes a product release of the Quarkus Maven Plugin (com.quarkus.redhat.platform:quarkus-maven-plugin). The product version of the plugin provides equivalent functionality to the community version and is used in projects that are generated by code.quarkus.redhat.com.

See the section about upgrading your applictions to Quarkus 2.2 for more information.

3.3. Extension registry for Red Hat build of Quarkus

Quarkus 2.2 introduces an extension registry that hosts Quarkus extensions provided by Red Hat. You can configure your Quarkus developer tools to access extensions in this registry by adding the registry to your registry client configuration file (for example, ~/.quarkus/config.yaml):

~/.quarkus/config.yaml

registries:
  - registry.quarkus.redhat.com
  - registry.quarkus.io

For more information about custom registry configuration, see the Quarkus Registry Client Configuration in the Quarkus community documentation.

3.4. Production support for RestEasy Reactive extensions

Red Hat build of Quarkus 2.2 introduces support for a set of RESTEasy Reactive extensions. RESTEasy Reactive is a fully reactive implementation of Jakarta RESTful WebServices (JAX-RS) based on reactive APIs provided by Eclipse Vert.x. You can upgrade your Quarkus application to RESTEasy Reactive from any other JAX-RS implementations and take advantage of the additional features that RESTEasy Reactive provides, including:

Support for handling requests with the multipart/form-data content type
Non-blocking method execution by default
Improved integration with Hibernate ORM, Apache Kafka, and Quarkus CDI
Automatic determining of the dispatch strategy based on the method return type

The following extensions are provided with Red Hat build of Quarkus with full production support:

quarkus-resteasy-reactive
quarkus-resteasy-reactive-jackson
quarkus-resteasy-reactive-jsonb

An additional RESTEasy Reactive extension is available with Red Hat build of Quarkus 2.2 as a Technology Preview:

quarkus-resteasy-reactive-qute

3.4.1. Automatic determining of the dispatch strategy based on the method return type

RESTEasy Reactive in Red Hat build of Quarkus 2.2 provides a capability for automatically determining the default dispatch strategy based on method signatures. This means that Quarkus evaluates the method return types in your application at build time and automatically determines whether a particular method is executed on the I/O thread, as an asynchronous operation, or on a worker thread, as a synchronous operation. With this functionality you do not need to explicitly annotate the methods in your code with the @Blocking or @NonBlocking annotations to determine what dispatch strategy is used to process requests that are handled using these methods. Note, that you can still use the @Blocking and @NonBlocking annotations to override the default dispatch strategy. This capability simplifies the way you design HTTP APIs, and reduces the time and amount of resources that your application needs to process requests.

The following examples show how Quarkus and RESTEasy Reactive can automatically determine the dispatch strategy for methods in different HTTP API implementation patterns:

Examples of automatically determining the dispatch strategy with RESTEasy Reactive

In the following example, the hello() method uses a synchronous method signature with a String return type. Quarkus evaluates the return type and sets the method to be executed on a worker thread. You can use the @Blocking annotation to explicitly set the method to be executed on a worker thread, but you are not required to do this when you use RESTEasy Reactive:
Example of synchronous execution in a method with a synchronous return type
```
import javax.ws.rs.GET;
import javax.ws.rs.Path;

@Path("/hello")
public class GreetingResource {

   @GET
   public String hello() {
       return "Hello";
   }
}
```
You can use the @NonBlocking annotation to explicitly set the method to be executed on the I/O thread, as shown in the following example:
Example of asynchronous execution in a method annotated with a @NonBlocking annotation
```
import io.smallrye.common.annotation.NonBlocking;

import javax.ws.rs.GET;
import javax.ws.rs.Path;

@Path("/hello")
public class GreetingResource {

   @GET
   @NonBlocking
   public String hello() {
       return "Hello";
   }
}
```
When you use RESTEasy Reactive, you can change the return type of the hello() method to an asynchronous data type, for example a Uni. You do not need to use the @NonBlocking annotation in this case, Quarkus evaluates the return type as asynchronous and automatically sets the hello() method to be executed on the I/O thread:
Example of asynchronous execution in a method with an asynchronous return type
```
import io.smallrye.mutiny.Uni;

import javax.ws.rs.GET;
import javax.ws.rs.Path;

@Path("/hello")
public class GreetingResource {

   @GET
   public Uni<String> hello() {
       return Uni.createFrom().item("Hello");
   }
}
```
When you use RESTEasy Reactive extensions, Quarkus automatically executes methods on the I/O thread when the methods contain asynchronous return types, for example:
Uni<T>
Multi<T>
CompletionStage<T>
Publisher<T>

For more information about new RESTEasy Reactive capabilities in Quarkus 2.2 see the guide about writing REST services with RESTEasy Reactive in the Quarkus community documentation.

3.5. New WebSockets Client and Server extensions based on Eclipse Vert.x

Red Hat build of Quarkus 2.2 introduces new extensions for WebSockets Client (io.quarkus:quarkus-websockets-client) and WebSockets Server (io.quarkus:quarkus-websockets) that are based on the implementation of the WebSockets protocol in Eclipse Vert.x. The new extensions replace the WebSockets extension based on Undertow (io.quarkus:quarkus-undertow-websockets) that was provided with Red Hat build of Quarkus 1.11. The old WebSockets extension based on Undertow is removed from the Red Hat build of Quarkus 2.2, but the community version of the io.quarkus:quarkus-undertow-websockets artifact is imported in the product BOM to ensure backwards compatibility of Red Hat build of Quarkus 2.2 with applications based on earlier releases of Red Hat build of Quarkus that still use the old WebSockets extension based on Undertow.

This change does not directly affect backwards compatibility with earlier releases of Red Hat build of Quarkus. As a recommended practice, consider using the new WebSockets extensions in new Quarkus projects that you create. You should also consider upgrading your existing applications to the new Quarkus WebSockets extensions.

Note, that if you have build automation tools for your Quarkus projects configured to use the Quarkus Undertow WebSockets extension, these tools are affected by the removal of the extension and their configuration will not work after you upgrade your applications to Red Hat build of Quarkus 2.2.

3.6. Automatic provisioning and configuration of services in development and test mode with Dev Services

Dev Services available with development support in Red Hat build of Quarkus 2.2. You can use Dev Services when developing applications with Red Hat build of Quarkus, but they are not intended for use in production environments.

Red Hat build of Quarkus 2.2 introduces automatic provisioning of services in development and test mode using the Dev Services capability.

Some of the available Quarkus extensions requires an external service that they can connect to, such as a database application or an identity server. In a typical development environment, you need to set up such services separately to simulate the production environment in order to effectively develop and test your application code.

With Dev Services you do not need to separately set up services for your extension to use in a development or test environment, or maintain dedicated test and development configuration profiles in your application configuration file. Instead, you can add an extension for a particular service to your project without configuring it, and start your application in development mode or test mode. When your application starts, Quarkus uses your container runtime environment to automatically create a container that provides the required service and automatically configures the extension in your application to use that service. Dev Service functionality does not affect the production configuration of your application.

Note, that you must have access to a Docker container runtime environment to enable Dev Services to automatically create containers. You can use Dev Services with a remote Docker environment.

Dev Service functionality is enabled by default on all Quarkus extensions that support it. Configuring an extension automatically disables Dev Service functionality for that extension. You can disable Dev Service functionality for all extensions in your project by setting the quarkus.devservices.enabled configuration property to false in your application configuration file.

In Red Hat build of Quarkus 2.2, the Dev Service functionality is available with the following Quarkus extensions:

Quarkus AMQP extension
Quarkus Apache Kafka extension
Quarkus SmallRye Reactive Messaging AMQP extension
Quarkus Redis extension
Quarkus MongoDB extension
Quarkus Vault extension
Quarkus OIDC extension
Quarkus Reactive DB2 client extension
Quarkus Reactive MySQL client extension
Quarkus Reactive PostgreSQL client extension
Quarkus JDBC Driver PostgreSQL extension
Quarkus JDBC Driver MySQL extension
Quarkus JDBC Driver Microsoft SQL extension
Quarkus JDBC Driver MariaDB extension
Quarkus JDBC Driver DB2 extension
Quarkus JDBC Driver H2 extension

For more information about Dev Services, see the overview of Dev Services in the Quarkus community documentation.

3.6.1. Dev Service for Apache Kafka

Red Hat build of Quarkus 2.2 provides a Dev Service for Apache Kafka that automatically creates an Apache Kafka broker that you can use for developing and testing your application.

To use the Dev Service for Apache Kafka, add the quarkus-kafka-client extension to your project without configuring the kafka.bootstrap.servers property, and start your application in development mode or test mode.

Note, that you must have access to a Docker container runtime environment to enable Dev Services to automatically create containers. You can use Dev Services with a remote Docker environment.

For more information about the Dev Service for Apache Kafka, see the overview of Dev Services and the AMQP Dev Service guide in the Quarkus community documentation.

3.6.2. Dev Service for AMQP 1.0

Red Hat build of Quarkus 2.2 provides a Dev Service that automatically creates an AMQP 1.0 broker that you can use for developing and testing your application.

To use the Dev Service for AMQP 1.0, add the quarkus-smallrye-reactive-messaging-amqp extension without to your project without configuring the amqp-host and amqp-port properties, and start your application in development mode or test mode.

Note, that you must have access to a Docker container runtime environment to enable Dev Services to automatically create containers. You can use Dev Services with a remote Docker environment.

For more information about the Dev Service for AMQP, see the overview of Dev Services and the AMQP Dev Service guide in the Quarkus community documentation.

3.6.3. Dev Service for OpenID Connect (OIDC)

Red Hat build of Quarkus 2.2 provides a Dev Service that automatically creates a Keycloak Server that you can use for developing and testing your application.

To use the Dev Service for OIDC, add the quarkus-oidc extension to your project without configuring any of the quarkus.oidc properties in your application.properties file, and start your application in development mode or test mode.

Note, that you must have access to a Docker container runtime environment to enable Dev Services to automatically create containers. You can use Dev Services with a remote Docker environment.

For more information about the Dev Service for OIDC, see the overview of Dev Services and the OIDC Dev Service guide in the Quarkus community documentation.

3.7. Continuous testing of Quarkus applications in development mode and test mode

Continuous Testing is available with development support in Red Hat build of Quarkus 2.2. Continuous testing is a functionality that you can use when developing applications with Red Hat build of Quarkus, but it is not intended for use in production environments.

Red Hat build of Quarkus 2.2 introduces the continuous testing functionality for your applications that provides instant feedback on changes that you make to your code as you develop your application. When you enable continuous testing, Quarkus detects when you make changes to your application code, and automatically executes the tests that cover the sections of your code that is affected by the changes. You can use continuous testing when your application is in development mode and test mode.

For more information about using continuous testing, see the Continuous testing guide in the community documentation.

3.8. Quarkus Apache Kafka components upgraded to version 2.8.0

In Red Hat build of Quarkus 2.2, components that are based on Apache Kafka are upgraded to Apache Kafka version 2.8.0.

3.9. Quarkus Reactive components upgraded to Eclipse Vert.x 4

In Red Hat build of Quarkus 2.2, the Eclipse Vert.x and Netty components are upgraded to Eclipse Vert.x version 4.

3.10. Quarkus SmallRye components upgraded to implement Microprofile 4

In Red Hat build of Quarkus 2.2, SmallRye Components have been upgraded to comply with the MicroProfile version 4 specification.

3.11. Quarkus upgraded to Hibernate ORM 5.5

In Red Hat build of Quarkus 2.2, components that are based on Hibernate are upgraded to use Hibernate version 5.5

3.12. BOMs productized and supported by Red Hat Build of Quarkus

Red Hat build of Quarkus 2.2 supports the following productized BOMs:

com.redhat.quarkus.platform:quarkus-bom: An equivalent of io.quarkus:quarkus-bom. Manages the dependencies of Quarkus core extensions.
com.redhat.quarkus.platform:quarkus-camel-bom: Manages only the Camel extensions and the dependencies they require.

You can import the productized BOMs in any order without creating a conflict.

4. Upgrading your applications from Red Hat build of Quarkus 1.11 to Red Hat build of Quarkus 2.2

In Red Hat build of Quarkus 2.2, the com.redhat.quarkus:quarkus-universe-bom BOM is deprecated. In Quarkus 2.2, the com.redhat.quarkus:quarkus-universe-bom BOM is split into separate member-specific BOMs, which are fragments of the com.redhat.quarkus:quarkus-universe-bom.

With Red Hat build of Quarkus 2.2, the following productized platform member BOMs are supported:

com.redhat.quarkus.platform:quarkus-bom
com.redhat.quarkus.platform:quarkus-camel-bom

Dependencies of community extensions that are part of the Quarkus platform are distributed by using the separate BOMs, which you must import separately into the pom.xml file of your project. This change is introduced to avoid conflicts of dependency versions in complex Quarkus applications.

Managing all dependency versions using a single BOM might lead to compatibility problems when different extensions that you use in your application individually depend on different versions of the same library. The new BOM structure avoids such versioning conflicts by configuring the dependency versions separately for individual extensions.

You can still use the original com.redhat.quarkus:quarkus-universe-bom BOM with Red Hat build of Quarkus 2.2 when you need to preserve backwards compatibility of your applications.

Quarkus projects based on the Red Hat build of Quarkus 2.2 release that are generated using the Quarkus Maven plug-in and code.quarkus.redhat.com use one of the new productized BOM files.

Procedure

In the pom.xml file of your project, rename the BOM from com.redhat.quarkus:quarkus-universe-bom to the required productized BOM file. For example, rename com.redhat.quarkus:quarkus-universe-bom to com.redhat.quarkus.platform:quarkus-bom.

pom.xml

<project>
  ...
  <properties>
      ...
      <quarkus.platform.group-id>com.redhat.quarkus.platform</quarkus.platform.group-id>
      <quarkus.platform.artifact-id>quarkus-bom</quarkus.platform.artifact-id>
      <quarkus.platform.version>2.2.5.Final-redhat-00007</quarkus.platform.version>
      ...
  </properties>
    ...
    <dependencyManagement>
      <dependencies>
        <dependency>
          <groupId>${quarkus.platform.group-id}</groupId>
          <artifactId>${quarkus.platform.artifact-id}</artifactId>
          <version>${quarkus.platform.version}</version>
          <type>pom</type>
          <scope>import</scope>
        </dependency>
      </dependencies>
    </dependencyManagement>
    ...
</project>

Add the BOMs of any Quarkus platform member extensions that you use in your application to the <dependencyManagement> section of your pom.xml file.

Platform member BOMs can be either productized or community-specific. Red Hat supports only the productized platform member BOMs, however, all platform member BOMs are fragments of com.redhat.quarkus:quarkus-universe-bom, which you can import into your pom.xml file in any order.
Update the groupId and version of the Quarkus Maven plug-in as shown in the following example:
pom.xml
```
<project>
  ...
  <build>
    ...
    <plugins>
      ...
      <plugin>
        <groupId>${quarkus.platform.group-id}</groupId>
        <artifactId>quarkus-maven-plugin</artifactId>
        <version>${quarkus.platform.version}</version>
        <extensions>true</extensions>
        <executions>
          <execution>
            <goals>
              <goal>generate-code</goal>
              <goal>generate-code-tests</goal>
              <goal>build</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
      ...
    </plugins>
    ...
  </build>
  ...
</project>
```
In Red Hat build of Quarkus 2.2, the groupId and version of the Quarkus Maven plug-in are aligned with the groupId and version of the Quarkus BOM. Therefore, you can use the same properties to manage both, that is, the groupId and version of the Quarkus BOM and the Maven plug-in, in the pom.xml file of your project. This helps to make the process of upgrading your applications to a new release of Red Hat build of Quarkus easier compared to earlier releases.

For new projects that are based on Red Hat build of Quarkus 2.2 and generated by code.quarkus.redhat.com, the Quarkus Maven plug-in and other Quarkus developer tools also use this new plug-in configuration.

Additional resources

Product Documentation for Red Hat Integration 2021.Q4

5. Changes that affect backwards compatibility with Red Hat build of Quarkus 1.11

This section describes changes that affect the backwards compatibility of Red Hat build of Quarkus 2.2 with applications based on Red Hat build of Quarkus 1.11. You must address these changes when upgrading your applications to Red Hat build of Quarkus 2.2 to ensure that you applications continue to function after the upgrade.

5.1. Change in the groupId and artifactId of the Red Hat Build of Quarkus BOM

In Red Hat build of Quarkus 2.2 the com.redhat.quarkus:quarkus-universe-bom BOM is deprecated. You must use the new com.redhat.quarkus.platform:quarkus-bom BOM to manage dependencies in your Quarkus projects.

For more information about changes to the Quarkus BOM introduced in Red Hat build of Quarkus 2.2, see the section about upgrading your application to Red Hat build of Quarkus 2.2.

5.2. Change of default JAR file packaging format to Fast JAR

Quarkus 2.2 uses Fast JAR as the default application packaging format. The Fast JAR packaging format provides faster startup times for your applications compared to the runner JAR packaging format that was the default packaging format in Quarkus 2.2.

With this change, the name format and location of the JAR file that you generate when packaging your application with Maven changes from target/<application-name>-<version>-runner.jar to target/quarkus-app/quarkus-run.jar. This change affects the JVM commands that you use to start your packaged application on the command line and the deployment commands in your Dockerfiles. If you use the default JAR packaging format to package your applications, ensure that you update the deployment commands in your Dockerfile.jvm to use the new name and location of the Fast JAR file. You must also update the deployment commands to deploy the entire target/ directory of your project, as shown in the following example:

Dockerfile.jvm

...
COPY --chown=1001 target/quarkus-app/lib/ /deployments/lib/
COPY --chown=1001 target/quarkus-app/*.jar /deployments/
COPY --chown=1001 target/quarkus-app/app/ /deployments/app/
COPY --chown=1001 target/quarkus-app/quarkus/ /deployments/quarkus/
...

If you want to continue using the legacy runner JAR packaging format, you must set the value of the quarkus.package.type property to legacy-jar in the application.properties file of your project:

application.properties

quarkus.package.type = legacy-jar

The change of the default JAR file packaging format to Fast JAR also affects the Dockerfiles generated in the src/main/docker directory when you create a new Quarkus project using the Quarkus Maven plugin:

In Quarkus 1.11, Dockerfile.jvm used the runner JAR file format and Dockerfile.fast-jar used the Fast JAR format.
In Quarkus 2.2 Dockerfile.jvm uses the Fast JAR packaging format and Dockerfile.legacy-jar uses the legacy versioned runner JAR format.

You must update the Dockerfiles in your existing projects when you want to use the Fast JAR format to deploy your applications after you upgrade to Red Hat build of Quarkus 2.2.

5.3. Change of default HTTP file upload settings

Quarkus 2.2 introduces change to the default file upload settings in HTTP. These changes affect all extensions that use the quarkus-http module as a dependency.

The quarkus.http.body.delete-uploaded-files-on-end property is enabled by default.

This change ensures that all files uploaded uploaded to a server are removed when the file transfer is complete. If you want to disable this behavior. You must disable the quarkus.http.body.delete-uploaded-files-on-end property in the application.properties file of your project:
application.properties
```
quarkus.http.body.delete-uploaded-files-on-end=false
```
The quarkus.http.body.uploads-directory property is set to store uploaded files in the ${java.io.tmpdir}/uploads directory be default. This change is intended to prevent file transfer issues that might occur when your application does not have permission to write to the working directory.

5.4. Changes in REST endpoint path resolution

In Red Hat build of Quarkus 2.2 paths of application and non-application REST endpoints are resolved relative to the common absolute root path. The default common root path for REST endpoints is set to:

/ for REST endpoints directly exposed by the main REST controller class of your application. You can change the default path for application endpoints by changing the value of the quarkus.http.root-path property in the application.properties file of your project.
q for REST endpoints for services provided by tools integrated with your application (for purposes such as application health monitoring or metrics collection). You can change the default path for non-application endpoints by changing the value of the quarkus.http.non-application-root-path property in the application.properties file of your project.

Note, that relative root paths are nested under the root path defined by the quarkus.http.root-path property. This means that, for example, if the root path defined in the quarkus.http.root-path property is set to /, and the root path for non-application endpoints defined by the quarkus.http.non-applicationroot-path property is set to q, the absolute endpoint path for the non-application endpoint is /q/<non-application-endpoint-name>.

However, you can also configure the paths of individual non-application endpoints explicitly to be located at /q/<non-application-endpoint-name>.

Because endpoint paths are interpreted as relative to the root paths set by quarkus.http.root-path and quarkus.http.non-application-root-path you must exclude the leading slash (/) character from the custom paths and sub-paths that you configure for endpoints in your application.

For example, when you expose a metrics endpoint for Prometheus in a REST Controller your application, you must set the endpoint path in the @Path annotation to metrics to ensure that your endpoint is exposed at /q/metrics. Setting the same path value to /metrics exposes your metrics endpoint at /metrics.

5.4.1. Removal of the configuration property for the automatic redirection of non-application endpoint paths

The quarkus.http.redirect-to-non-application-root-path configuration property introduced in Red Hat build of Quarkus 1.11 is removed in Red Hat build of Quarkus 2.2. If you are using this property to automatically redirect your non-application endpoint paths (for example /health or /metrics) to the /q namespace (that is, for example /q/health and /q/metrics), the redirection no longer works after you upgrade your application.

If you want to expose non-application endpoints at the root endpoint path (/), you must configure the endpoint path explicitly for each service.

Examples of updating non-application endpoint paths

Quarkus MicroProfile Health

For example, to configure the Health endpoint for the Quarkus MicroProfile Health to be available at the /health path instead of /q/health, you must add the following configuration property to the application.properties file of your project:

application.properties

quarkus.smallrye-health.root-path=/health

Quarkus Micrometer Prometheus

To configure the Metrics endpoint for Prometheus ServiceMonitor to be available at the /metrics path instead of /q/metrics, you must add the following configuration property to the application.properties file of your project:

application.properties

quarkus.micrometer.export.prometheus.path=/metrics

For all Quarkus extensions that are based on Prometheus, you must also update the endpoint path in the prometheus.yml configuration file to ensure that Prometheus continues to be able to collect application metrics after you upgrade to Red Hat build of Quarkus 2.2.

prometheus.yml

...
scrape_configs:
  - job_name: "prometheus"
    - metrics_path: /q/metrics
...

5.5. Removal of Response from javax.ws.rs.WebApplicationException in Quarkus REST CLient and Quarkus RESTEasy JAX-RS Client

Quarkus 2.2 includes a change to javax.ws.rs.WebApplicationException in JAX-RS that affects the Quarkus REST Client and Quarkus RESTEasy JAX-RS Client extensions.

As a result of this change, the javax.ws.rs.WebApplicationException that can be thrown by Quarkus REST Client and Quarkus RESTEasy JAX-RS Client no longer contains a JAX-RS Response by default.

This change is intended to prevent the exposure of cookies or other potentially sensitive data about downstream endpoints.

If you want to include the Response in javax.ws.rs.WebApplicationException after upgrading to Red Hat build of Quarkus 2.2, you must set the resteasy.original.webapplicationexception.behavior property to true in the application.properties file of your project.

For more information about this change, see the section about ResteasyWebApplicationException in the RestEasy community documentation.

5.6. Change of the default timestamp serialization format to ISO-8601 in Jackson Object Mapper

This change affects Red Hat build of Quarkus applications that use the following dependencies:

Quarkus Jackson
Quarkus RESTEasy Jackson
Quarkus REST Client Jackson
Quarkus RESTEasy Reactive Jackson

In Red Hat build of Quarkus 2.2, the SerializationFeature.WRITE_DATES_AS_TIMESTAMPS feature in the Jackson Object Mapper is disabled by default. This means that in Red Hat build of Quarkus 2.2, when generating JSON outputs for your application data, Jackson converts dates and times in your data objects to strings that follow the format mandated by the ISO-8601 standard (for example, 1988-11-17T00:00:00Z) instead of the previously used Unix epoch format (for example, 595728000), unless you explicitly enable this feature.

If you use Jackson to convert your application data to JSON format, and want to keep using the Unix epoch format for your timestamps after upgrading your application to Red Hat build of Quarkus 2.2, you must set the quarkus.jackson.write-dates-as-timestamps property to true in the application.properties file of your project:

application.properties

quarkus.jackson.write-dates-as-timestamps=true

5.7. Replacement of the deprecated uberJar Maven parameter and quarkus.package.uber-jar configuration property with the quarkus.package.type configuration property

The previously deprecated uberJar Maven parameter and quarkus.package.uber-jar configuration property are removed in Red Hat build of Quarkus 2.2. As a result, any settings or configurations that contain this parameter or property do not work after upgrading your application to Red Hat build of Quarkus 2.2. To ensure that you are able to continue packaging your application in Uber JAR format settings and configuration continue to work after upgrading your application, replace the quarkus.package.uber-jar property and uberJar Maven parameter with the quarkus.package.type=uber-jar property in your application.properties and pom.xml files.

5.8. Removal of the native-image goal for the Quarkus Maven plugin

In Red Hat build of Quarkus 2.2, the previously deprecated native-image goal is removed from Quarkus Maven Plugin

Quarkus Maven Plugin configurations that use the native-image Maven goal to configure Quarkus Maven Plugin to generate a native executable do not work you upgrade your application to Red Hat build of Quarkus 2.2.

To ensure that you plugin configuration continues to work after you upgrade your applications, you must remove the native-image Maven goal and use the quarkus.package.type property to configure Maven to generate a native executable form you project. You must specify the quarkus.package.type in the build profile that you use to generate the native executable in the pom.xml file of your project, as shown in the example:

pom.xml

...
<profiles>
  ...
    <profile>
        <id>native</id>
        <properties>
            <quarkus.package.type>native</quarkus.package.type>
        </properties>
    </profile>
  ...
</profiles>
...

5.9. Change of configuration property names for native executables

Red Hat build of Quarkus 2.2 introduces changes to the names of configuration properties that you use to configure Maven to generate native executables from your Red Hat build of Quarkus projects.

If you use native executable configuration properties from Red Hat build of Quarkus in your application.properties or pom.xml file to override the default settings for generating native executables, the old property names used in Red Hat build of Quarkus 1.11 are no longer recognized after you upgrade your application to Red Hat build of Quarkus 2.2.

To ensure that your native executable configuration continues to work after you upgrade your application, you must change the property names in your configuration to match the property names used for configuring native executables in Red Hat build of Quarkus 2.2.

5.10. Change of minimum required Apache Maven version to 3.8.1

In Red Hat build of Quarkus 2.2 the minimum version of Apache Maven required for compiling Red Hat build of Quarkus projects changes to 3.8.1. You must upgrade your installation of Apache Maven to version 3.8.1 to be able to compile projects based on Red Hat build of Quarkus 2.2. This upgrade is required because it addresses a security issue that can potentially make your Apache Maven builds vulnerable to man-in-the-middle attacks. For more information about this security vulnerability, see the entry about CVE-2021-26291 on the Red Hat Customer Portal.

5.11. Change in version of Jandex that affects Jandex plugins for Apache Maven

The version of the Jandex Java annotation indexer dependency that is included with the Red Hat build of Quarkus BOM has been upgraded to version 2.4.0. If you are using the Jandex Maven plugin, you must upgrade it to version 1.1.0 to ensure that it continues to work after you upgrade your applications to Red Hat build of Quarkus 2.2.

5.12. Change of the names of configuration properties for JWT sign and encrypt key locations in SmallRye JWT

The names of the following configuration properties for the SmallRye JWT library are changed in Red Hat build of Quarkus 2.2:

The smallrye.jwt.sign.key-location property is renamed to smallrye.jwt.sign.key.location.
The smallrye.jwt.encrypt.key-location property is renamed to smallrye.jwt.encrypt.key.location.

You must update the names of these properties in your application.properties file to ensure that your Role-Based Access Control (RBAC) configuration continues to work after you upgrade your applications to Red Hat build of Quarkus 2.2.

5.13. Changes to annotations in Quarkus gRPC

Red Hat build of Quarkus 2.2 introduces changes that affect the use of annotations for the Quarkus gRPC library. You must make the following changes to the way that you annotate your services to ensure that your annotations work after your upgrade your applications to Red Hat build of Quarkus 2.2:

The io.quarkus.grpc.runtime.annotations.GrpcService annotation is renamed to io.quarkus.grpc.GrpcClient. You must update the name of this annotation if you use it in your code.
The previously required @GrpcClient.value() field is optional. You do not need to specify a value for it, because Quarkus gRPC derives the name of the service from the annotated element.
If you use the @javax.inject.Singleton annotation to annotate your services, you must replace this annotation with the @io.quarkus.grpc.GrpcService annotation.

5.14. Changes to annotation names in Quarkus RESTEasy due to the removal of the deprecated io.quarkus.qute.api package

The previously deprecated io.quarkus.qute.api package is removed in Red Hat build of Quarkus 2.2 and the @io.quarkus.qute.api.CheckedTemplate and @io.quarkus.qute.api.ResourcePath annotations provide by this package are no longer available. If you use these annotations in your class files, you must change them in the following way to ensure that your Qute Template Engine annotations continue to work after you upgrade your application to Red Hat build of Quarkus 2.2:

Change all @io.quarkus.qute.api.CheckedTemplate annotations in your code to @io.quarkus.qute.CheckedTemplate.

Note, that by default, Checked templates require that you use type-safe expressions, that is, expressions that can be validated at build time. If you want to use type-unsafe expression, you can add the requireTypeSafeExpressions=false property to your @CheckedTemplate annotations to disable this requirement.
Change all @io.quarkus.qute.api.ResourcePath annotations in your code to @io.quarkus.qute.Location.

5.15. Removal of the deprecated quarkus.quartz.force-start property from the Quarkus Quartz extension

The quarkus.quartz.force-start property used by the Quarkus Quartz extension is removed in Red Hat build of Quarkus 2.2. If you use this property in the configuration of your project, the property no longer works after you upgrade your application.

If you want to configure your Quarkus Quartz Scheduler to start in forced mode in Red Hat build of Quarkus 2.2, you must set the value of the quarkus.quartz.start-mode configuration property to forced in the application.properties file of your project.

application.properties

quarkus.quartz.start-mode=forced

For more information, see the Quarkus Quartz property reference in the community documentation.

5.16. Removal of the StoreType.DB configuration value from Quarkus Quartz Scheduler

The previously deprecated StoreType.DB configuration value for the quarkus.quartz.store-type configuration property is removed in Red Hat build of Quarkus 2.2. If you use the quarkus.quartz.store-type=db configuration property to configure a database for persisting data for your Quartz jobs, this value is not recognized after you upgrade your application. You must change the value of the quarkus.quartz.store-type property in your application.properties file to jdbc-cmt to ensure that your configuration continues to work after upgrading.

application.properties

quarkus.quartz.store-type=jdbc-cmt

5.17. Change in the configuration of the connection pool size limit for reactive data sources

In Red Hat build of Quarkus 2.2, the connection pool size limit set using the datasource.reactive.max-size configuration property for reactive data sources applies to the entire pool. This is a change from Red Hat build of Quarkus 1.11, where a separate connection pool was created for each thread, and it was required that you used the datasource.reactive.max-size property to set the size limit individually for each connection pool. In Quarkus 2.2, reactive data sources use one connection pool that is shared among all threads. If you use reactive data sources in your application, you must remove the connection pool size limit settings for each connection pool instance and use the datasource.reactive.max-size property to set common connection pool size limit for all instances.

5.18. New method signatures in the AuthenticationRequest interface in the Quarkus Security extension

Red Hat build of Quarkus 2.2 introduces an a update to the Quarkus Security extension that adds new method signatures to the AuthenticationRequest interface. This change allows you to include additional context information, such as context path, HTTP header, or query parameter values in an authentication request that is issued by a class that implements the AuthenticationRequest interface.

If you implement the AuthenticationRequest interface from Red Hat build of Quarkus 1.11 in the classes of application, you need to update these classes to ensure that your application compiles after upgrading to Red Hat build of Quarkus 2.2. To do this, you can extend the BaseAuthenticationRequest abstract class to inherit methods from the AuthenticationRequest interface without having to implement the new methods.

5.19. Change in object mapper configuration for Eclipse Vert.x components

Eclipse Vert.x components in Red Hat build of Quarkus 2.2 depend on the Jackson Object Mapper that is managed by the Quarkus BOM. As a result, you should not use the former method of customizing the Jackson object mapper for Eclipse Vert.x in a Json class.

Instead, your Quarkus extensions based on Eclipse Vert.x components can obtain the default ObjectMapper form Quarkus using Context and Dependency Injection (CDI). To customize your ObjectMapper, you can create a io.quarkus.jackson.ObjectMapperCustomizer CDI bean that contains the custom configuration, and and use it to apply the configuration to your ObjectMapper. The following example shows a class that can be used to register a customized ObjectMapper module:

RegisterCustomModuleCustomizer.java

import com.fasterxml.jackson.databind.ObjectMapper;
import io.quarkus.jackson.ObjectMapperCustomizer;
import javax.inject.Singleton;

@Singleton
public class RegisterCustomModuleCustomizer implements ObjectMapperCustomizer {

    public void customize(ObjectMapper mapper) {
        mapper.registerModule(new CustomModule());
    }
}

For more details about configuring JSON support for you Quarkus REST services, see the guide to https://quarkus.io/guides/rest-json#json in the Quarkus community documentation.

5.20. Change in the annotation used to access the default configuration of the Apache Kafka broker in Quarkus SmallRye Reactive Messaging

Red Hat build of Quarkus 2.2, introduces a change in the Quarkus SmallRye Reactive Messaging extension that changes the methods that the extension uses to access the default Apache Kafka Producer API. In earlier releases of Red Hat build of Quarkus, calling the KafkaClientService.getProducer() returns the org.apache.kafka.clients.producer.Producer API. In Red Hat build of Quarkus 2.2, calling the KafkaClientService.getProducer() method returns the Uni-based io.smallrye.reactive.messaging.kafka.KafkaProducer API.

The underlying reason for this change is that the org.apache.kafka.clients.producer.Producer API does in some situations exhibit blocking behavior when returning a Future object. In Red Hat build of Quarkus 2.2, the io.smallrye.reactive.messaging.kafka.KafkaProducer API used by the Quarkus SmallRye Reactive Messaging extension uses a dedicated sending thread to send records to the Kafka Broker to ensure that the API is always asynchronous.

As a result of this change, the @Named annotation that was required by the org.apache.kafka.clients.producer.Producer API no longer works. The new API requires that you use the @Identifier annotation to access the default configuration of your Apache Kafka Broker, as shown in the following example:

@ApplicationScoped
public class KafkaProviders {

    @Inject
    @Identifier("default-kafka-broker")
    Map<String, Object> config;
}

For more information, see the API documentation for the io.smallrye.reactive.messaging.kafka.KafkaProducer interface.

5.21. Changes to package names in Hibernate ORM with Panache and MongoDB with Panache extentions to avoid split packages

In Red Hat build of Quarkus 2.2, several classes in the Quarkus Hibernate ORM with Panache and Quarkus MongoDB with Panache have been moved to different package names to avoid split packages. If you import the packages listed in the following sections in your projects, you must update the names of these packages to ensure that your application compiles after you upgrade it to Red Hat build of Quarkus 2.2.

5.21.1. Hibernate ORM with Panache

The ProjectedFieldName class has been moved from the io.quarkus.hibernate.orm.panache package to the io.quarkus.hibernate.orm.panache.common package.

5.21.2. MongoDB with Panache

The MongoEntity class has been moved from the io.quarkus.mongodb.panache package to the io.quarkus.mongodb.panache.common package.
The ProjectionFor class has been moved from the io.quarkus.mongodb.panache package to the io.quarkus.mongodb.panache.common package.
The PanacheUpdate class has been moved from the io.quarkus.mongodb.panache package to the io.quarkus.mongodb.panache.common package.
The ReactivePanacheUpdate class has been moved from the io.quarkus.mongodb.panache.reactive package to the io.quarkus.mongodb.panache.common.reactive package.

5.22. Change in the behavior of the @WithName annotation when mapping configurations to objects

In Red Hat build of Quarkus 2.2, the @WithName annotation that is used with the @ConfigMapping annotation to override the name of a configuration property when mapping configurations to objects no longer changes the format of the property name that it maps to.

For example, in earlier releases of Red Hat build of Quarkus, the following mapping maps to the server.test-host configuration property:

@ConfigMapping(prefix = "server")
interface Server {
 @WithName("testHost")
 String server();
}

In Red Hat build of Quarkus 2.2 the same mapping maps to the name of the property exactly as it is specified in the @WithName annotation. In this example that is the server.testHost configuration property.

You must update the property names that you use in your @WithName annotations to ensure that your configuration mappings match the correct property names after you upgrade your application to Red Hat build of Quarkus 2.2.

For more information, see the guide to configuration mappings in the Quarkus Community documentation.

5.23. New mode in SmallRye Fault Tolerance for determining asynchrony of methods based on return types

In Red Hat build of Quarkus 2.2 SmallRye Fault Tolerance is upgraded to version 5.2.

Version 5.2 introduces a new mode for determining the asynchrony of methods based on return types. Note, that this mode is not compatible with the MicroProfile Fault Tolerance specification.

In this mode, methods that are annotated with MicroProfile Fault Tolerance annotations are automatically executed on a separate thread when they use an asynchronous return type (for example, a CompletableFuture, CompletionStage, Uni, or Multi return type) even when they are not annotated with asynchronous annotations (for example, any of the , @Blocking, or @NonBlocking annotations).

For methods that are annotated with asynchronous annotations, asynchrony is determined based on the annotations rather than based on the return types that the methods use.

In Red Hat build of Quarkus 2.2, the non-compatible mode for determining asynchrony of methods is enabled by default. If you need your application to fully comply with the MicroProfile Fault Tolerance specification after you upgrade it to Red Hat build of Quarkus 2.2, you must set the following configuration property in the application.properties file of your project:

smallrye.faulttolerance.mp-compatibility=true

For more information, see the section about the non-compatible mode in the Smallrye Fault Tolerance 5.2.1 documentation.

5.24. Removal of the unsupported extensions that provide the Eclipse Vert.x Axle and Eclipse Vert.x RxJava 2 APIs

The Eclipse Vert.x Axle and Eclipse Vert.x RxJava 2 reactive APIs were not supported for use in production environments in earlier releases of Red Hat build of Quarkus.

The extensions that provide the Eclipse Vert.x Axle reactive API (io.smallrye.reactive:smallrye-axle-web-client) and the Eclipse Vert.x RxJava 2 reactive API (io.vertx:vertx-rx-java2) are removed in Red Hat build of Quarkus 2.2.

As a result, you will not be able to access the Axle and RxJava 2 Eclipse Vert.x APIs in your code using the @Inject annotation or by importing them from the smallrye-axle-web-client and vertx-rx-java2 libraries. If you rely on these libraries to provide Eclipse Vert.x APIs in your applications based on earlier releases of Red Hat build of Quarkus, these applications will not work after you upgrade them to Red Hat build of Quarkus 2.2.

To ensure that your reactive API implementations continue to work after you upgrade to Red Hat build of Quarkus 2.2, you must refactor them to use the Eclipse Vert.x Core API that is provided by the Quarkus Mutiny library (io.quarkus:quarkus-muntiny).

pom.xml

<dependency>
    <groupId>io.quarkus</groupId>
    <artifactId>quarkus-mutiny</artifactId>
</dependency>

To access the Eclipse Vert.x Core API form Mutiny using the @Inject annotation in your code, you can use the method shown in the following example:

@Inject io.vertx.core.munity.Vertx vertx;

To import the Eclipse Vert.x Core API form Mutiny, you can use the following import statement:

import io.vertx.mutiny.core.Vertx;

For more information about using the Eclipse Vert.x Core API from Mutiny in Quarkus, see the guide about using the Eclipse Vert.x Core API in the Quarkus Community documentation.

5.25. Change of the default asynchronous return type for Quarkus Mailer from CompletionStage to Uni

In Red Hat build of Quarkus 2.2, MailTemplateInstance method uses the Uni as the return type. This is a change from the CompletionStage interface that was previously used for asynchronous actions by the Quarkus Mailer extension.

This change affects the way your client handles subscriptions to the publisher how the returned data is used to complete the action:

Uni: represents a lazy asynchronous action. It follows the subscription pattern, which means that an action is only triggered when a UniSubscriber subscribes to the Uni. Therefore when using a Uni, every new subscription can trigger the operation again and get a different result.
CompletionStage: represents an eager asynchronous action. When a method returns a CompletionStage, the operation has already been triggered and the outcome of the operation is used to complete the returned CompletionStage. CompletionStage also caches its outcome, allowing you to repeatedly retrieve the result that you receive without triggering a new action.

If you need to obtain a CompletionStage from a Uni return type, you can call the .subscribeAsCompletionStage() method on returned Uni type.

CompletionStage<String> cs = uni.subscribeAsCompletionStage();

Note, that when retrieving a CompletionStage by calling the subscribe .subscribeAsCompletionStage() method on a Uni, if you perform the action twice, you will re-trigger the operation and might obtain a different result.

For more information about converting Uni return types to CompletionStage, see the guide to interacting with CompletionStage types in the community documentation for SmallRye Mutiny.

5.26. Change in the location of the enum for HTTP verb constants used when configuring method attributes for non-blocking endpoints with the Quarkus Reactive routes extension.

Red Hat build of Quarkus 2.2 introduces a change to the name of the package that contains the enum of the HTTP verb constants specified with the @Route annotation for configuring the name of the HTTP method that triggers the reactive route. This change affects applications that implement non-blocking REST endpoints using the Quarkus Reactive Routes extension (io.quarkus:quarkus-vertx-web) and use the @Route annotations to declare reactive routes. In earlier releases of Red Hat build of Quarkus, the enum that contains the HTTP verb constants (for example, GET, PUT, POST, and others) was defined in the io.vertx.core.http.HttpMethod. In Red Hat build of Quarkus 2.2 the enum for HTTP verb constants is defined in the io.quarkus.vertx.web.Route.HttpMethod package.

To ensure that the reactive route declarations in your application continue to work after upgrading to Red Hat build of Quarkus 2.2, ensure that you import the io.quarkus.vertx.web.Route.HttpMethod package instead of the io.vertx.core.http.HttpMethod package when you declare reactive routes.

For more information, see the section about Declaring reactive routes in the community documentation for the Quarkus Reactive Routes extension.

5.27. Change in the implementation pattern for asynchronous message processing in database transactions with Apache Kafka and Narayana

Red Hat build of Quarkus 2.2 introduces a new pattern for implementing asynchronous message processing in database transactions with Apache Kafka and Narayana.

When you implement asynchronous message processing with entities managed by Narayana in a transaction, for example, for sending a managed entity instance to Apache Kafka, ensure that you wait until Kafka acknowledges the message before letting Quarkus complete the transaction. To achieve this, you must use the emitter.send(instance).toCompletableFuture().join() method, as shown in the following example:

@Transactional(REQUIRED)
public Fight persistFight(Fighters fighters) {
   Fight fight = Fight.class.newInstance();
   fight.persist(fight);
   emitter.send(fight).toCompletableFuture().join(); 1
   return fight;
}

Convert the object to a CompletableFuture type and wait for completion.

When you implement this pattern, the execution of the .send() method is moved to a worker thread until Kafka sends a callback to confirm that it received the message that contains the managed entity instance. In case Kafka does not confirm the reception of the message, the transaction is rolled back.

As a result, the managed entity instance can not be accessed by another service after the transaction is complete. Therefore, the transaction can only be committed after the successful completion of the asynchronous operation that sends the managed entity to Kafka.

Implementing this pattern ensures that the managed entity instance that you send to the Kafka Broker remains protected and cannot be accessed by any other process before it is written to the message that is sent to the Kafka broker.

For more details about how you can implement the new transaction pattern, see the Apache Kafka reference guide in the Quarkus community documentation.

6. Red Hat build of Quarkus supported platforms, configurations, extensions, and dependencies

For a list of supported configurations, OpenJDK versions, and tested integrations see the Red Hat build of Quarkus Supported Configurations page (login required).
For a list of supported Maven artifacts see the Red Hat build of Quarkus Component Details page (login required).

6.1. Tested and verified environments

Red Hat build of Quarkus is supported on the following platforms:

Red Hat Enterprise Linux 8
Red Hat OpenShift Container Platform 3.11 on x86_64
Red Hat OpenShift Container Platform 4.6 on x86_64
Red Hat OpenShift Container Platform 4.8 on x86_64
Red Hat OpenShift Container Platform 4.8 on IBM Z (supported with Quarkus 2.2.5)

For a list of supported configurations, see the Red Hat build of Quarkus Supported Configurations page (login required).

6.2. Supported extensions & plugins

For a list of Red Hat build of Quarkus extensions, dependencies, and plugins that Red Hat supports for use in production environments see the Red Hat build of Quarkus Component Details page (login required).

The following supported extensions and plugins are added in Red Hat build of Quarkus 2.2:

Extensions

Quarkus Apache Avro
Quarkus JAX-RS Client Reactive
Quarkus JDBC Driver - Microsoft SQL Server
Quarkus JDBC Driver - Oracle (Only supported for use in JVM mode. Not supported for use in native executables)
Quarkus Reactive MySQL client
Quarkus Reactive PostgreSQL client
Quarkus REST Client Reactive
Quarkus REST Client Reactive Jackson
Quarkus RestEasy Reactive
Quarkus RestEasy Reactive Jackson
Quarkus RestEasy Reactive JSON-B
Quarkus WebSockets
Quarkus WebSockets Client

Plugins

Red Hat build of Quarkus Maven Plugin

6.3. BOMs productized and supported by Red Hat Build of Quarkus

Red Hat build of Quarkus 2.2 supports the following productized BOMs:

com.redhat.quarkus.platform:quarkus-bom
com.redhat.quarkus.platform:quarkus-camel-bom

6.4. 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
Remote development mode
Dev UI

Plugins

Maven Protocol Buffers Plugin

7. Deprecated components and features

The components and features listed in this section are deprecated with Red Hat build of Quarkus 2.2. 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 components and features deprecated in Red Hat build of Quarkus 2.2 Red Hat build of Quarkus Component Details page (login required).

The quarkus-undertow-websockets extension is deprecated in favor of the quarkus-websockets extension that is based on Eclipse Vert.x.
The com.redhat.quarkus:quarkus-universe-bom BOM is deprecated in favor of the com.redhat.quarkus.platform:quarkus-bom BOM. For more information, see the section about Upgrading your applications from Red Hat build of Quarkus 1.11 to Red Hat build of Quarkus 2.2

OpenJDK 11 and OpenJDK 17 OpenShift images support multiple architectures

OpenJ9 images for IBM Z and IBM Power Systems will be deprecated. The deprecation affects the following base image that Red Hat supports for Red Hat build of Quarkus:

openj9/openj9-11-rhel8

As an alternative to the deprecated image, use the following universal base images for deploying Red Hat build of Quarkus applications to OpenShift on IBM Z and IBM Power based infrastructures:

ubi8/openjdk-11

You can use the OpenJDK11 universal base images with the following architectures:

x86 (AMD64)
s390x (IBM Z)
ppc64le (IBM Power Systems)

If you want to use the OpenJ9 Java Virtual Machine (JVM) with the OpenJDK11 images, see Java Change in Power and IBM Z OpenShift Images.

8. Technology preview

This section lists features and extensions that are available as Technology Preview in Red Hat build of Quarkus 2.2.

The features and components listed in this section are provided as Technology Preview. Technology Preview features are not supported with Red Hat production service level agreements (SLAs), might not be functionally complete, and Red Hat does not recommend to use them for 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 on Red Hat Technology Preview features, see Technology Preview Features Scope.

8.1. Technology Preview extensions and dependencies

For a list of extensions and dependencies available as Technology Preview in Red Hat build of Quarkus 2.2, see the Red Hat build of Quarkus Component Details page (login required).

Quarkus RestEasy Reactive Qute
Quarkus Reactive Rest Client (Mutiny)
Quarkus RestEasy Reactive MicroProfile REST Client
Quarkus Kubernetes Service Binding
Quarkus Reactive Microsoft SQL Server
Quarkus Oracle JDBC Driver

9. Known issues

This section lists known issues with Red Hat build of Quarkus 2.2.

9.1. Deploying a Quarkus application on OpenShift 3.11 with S2I using the Quarkus OpenShift extension results in build failure

Description

In Quarkus 2.2, build failures occur when you use Quarkus OpenShift extension to build and deploy Quarkus applications to OpenShift 3.11.

These build failures are caused by an error in build log streaming rather than an actual problem with the Maven build. Due to an internal race condition in the log streaming implementation in the Quarkus OpenShift extension, an operation to close the log stream is executed on one thread, before an operation to read form the closed log stream is executed on another thread. As a result, the operation that reads form the log stream cannot be successfully completed, due to being unable to access the log stream.

This situation causes Maven to produce a java.io.IOException: Pipe closed exception, causing a build error and marking the build as a failure. When this issue occurs, you see an error in the log output of the affected Maven build that is similar to the one shown in the following example :

04:14:49.625 INFO  mvn: [ERROR] Caused by: java.io.IOException: Pipe closed
04:14:49.625 INFO  mvn: [ERROR] 	at java.base/java.io.PipedInputStream.read(PipedInputStream.java:307)
04:14:49.626 INFO  mvn: [ERROR] 	at java.base/java.io.PipedInputStream.read(PipedInputStream.java:377)
04:14:49.626 INFO  mvn: [ERROR] 	at java.base/sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
04:14:49.626 INFO  mvn: [ERROR] 	at java.base/sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
04:14:49.626 INFO  mvn: [ERROR] 	at java.base/sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
04:14:49.626 INFO  mvn: [ERROR] 	at java.base/java.io.InputStreamReader.read(InputStreamReader.java:181)
04:14:49.626 INFO  mvn: [ERROR] 	at java.base/java.io.BufferedReader.fill(BufferedReader.java:161)
04:14:49.626 INFO  mvn: [ERROR] 	at java.base/java.io.BufferedReader.readLine(BufferedReader.java:326)
04:14:49.627 INFO  mvn: [ERROR] 	at java.base/java.io.BufferedReader.readLine(BufferedReader.java:392)
04:14:49.627 INFO  mvn: [ERROR] 	at io.quarkus.container.image.openshift.deployment.OpenshiftProcessor.openshiftBuild(OpenshiftProcessor.java:444)

Workaround

Do not use the Quarkus OpenShift Extension to deploy your applications to OpenShift 3.11 using the S2I build strategy. As a workaround, you can use the oc command line tool to set up an S2I build and build and deploy your application:

Import the base image that you want to your in your build from the Red Hat Ecosystem Catalog:
- When you deploy your application to an OpenShift cluster on AMD64-based infrastructure, you must use the ubi8/openjdk-11 image stream:
```
oc import-image --confirm ubi8/openjdk-11 --from=registry.access.redhat.com/ubi8/openjdk-11
```
- When you deploy your application to an OpenShift cluster on IBM Z, you must use the openj9/openj9-11-rhel8 image stream:
```
oc import-image openj9/openj9-11-rhel8 --from=registry.redhat.io/openj9/openj9-11-rhel8 --confirm
```
Create the S2I build by pecifying the following information during the build creation:
- Name of the base image that you want to use.
- URL of the Git repository that contains the source code of your application.
- Name of the project into which you want to deploy your application.
```
oc new-app <base_image_name> <git_repository_url> --name=<project_name>
```
Start the S2I build:
```
oc start-build <project_name>
```
Verify that your build starts:
1. Wiew the list of pods in your project and identify the name of the pod in which your S2I job is running:
```
oc get pods
```
```
NAME                           READY   STATUS     RESTARTS   AGE
<application_name>-1-build   1/1     Running    0          1m
```
2. View the log output of the build pod to monitor the status of your S2I build:
```
oc logs -f <pod_name>
```

9.2. CoreDNS is unable to resolve the domain name for github.com in OpenShift 4.8 on OpenStack

Description

In OpenShift 4.8 on OpenStack, the CoreDNS settings on the cluster nodes prevent CoreDNS from resolving the domain name for github.com. This issue might affect source-to-image (S2I) builds of Quarkus applications by preventing S2I build pods from cloning Git repositories hosted on github.com.

This issue occurs because the size of the response that CoreDNS obtains from the dig DNS lookup utility when resolving the github.com domain name exceeds the default maximum buffer size for CoreDNS. As a result, unless the CoreDNS client specifies a larger maximum buffer size using the edns0 in the request that it sends to the DNS lookup tool, CoreDNS truncates the response to fit the maximum default buffer size. In this case, the CoreDNS client does not include the edns0 parameter in the original request, which results in receiving a truncated response that is not properly validated and causes the domain name resolution to fail.

Workaround

As a workaround to this issue:

Set the maximum buffer size for CoreDNS to 512 bytes.
Set the buffer size individually for each of the nodes on your cluster.

For more information about this issue and the workaround, see BZ #1991067

9.3. Keycloak 15.0.2 fails on start for RHEL8.5 instances with FIPS support

Description

The Quarkus Keycloak dev services do not work on FIPS-enabled RHEL8.5 instances.

For more information about this issue, see QUARKUS-1457

9.4. Quarkus native executable compilations fail in FIPS-compliant environments

Description

Currently, generating a native image of your application on a FIPS-enabled host system is not supported. If FIPS compliance is required for your application, run it in the JVM mode.

To check if your host system is FIPS enabled, use the fips-mode-setup --check command

fips-mode-setup --check

FIPS mode is enabled.

Workaround

As a workaround for this issue, pass the -Dcom.redhat.fips=false command to the native image generator to create the no-FIPS compliant image.

./mvn package -Pnative [...] -Dquarkus.native.additional-build-args="-Dcom.redhat.fips=false"

For more information about this issue, see QUARKUS-1417.

9.5. Missing dependencies for `quarkus-universe-bom`

Description

Red Hat build of Quarkus introduced a platform feature that will help align Red Hat build of Quarkus with other products such as Camel-K extensions for Quarkus. However, the issue occurs if the deprecated quarkus-universe-bom, with missing dependencies, is in use.

We recommend you switch from deprecated quarkus-universe-bom to the productized com.redhat.quarkus.platform:quarkus-bom version for the proper functionality.

The use of the deprecated image will cause an issue of improper alignment with the productized Camel-K extensions.

For more information about this issue, see QUARKUS-1752.

9.6. Stability issues for deployment of a serverless application into OCP

Description

Deploying a serverless application on OCP can trigger an error in OpenStack nodes, causing the service to fail deploying. As a result, users cannot use OCP in production with guaranteed stability.

This issue has been observed in the following software:

OpenShift Version: 4.8
Quarkus Version: 2.2.5.Final
Knative Operator version: Red Hat OpenShift Serverless: 1.19.0

For more information about this issue, see QUARKUS-1724.

10. Other fixes

Quarkus 2.2.5 provides increased stability with security fixes and resolved issues listed in this section.

10.1. Security fixes

QUARKUS-1636 CVE-2021-4178 kubernetes-client: Insecure deserialization in the unmarshalYaml method
QUARKUS-1444 CVE-2021-41269 cron-utils: Template Injection leading to unauthenticated Remote Code Execution
QUARKUS-1418 CVE-2021-2471 mysql-connector-java: Unauthorized access to critical
QUARKUS-1353 CVE-2021-38153 kafka-clients: Kafka: Timing Attack Vulnerability for Apache Kafka Connect and Clients
QUARKUS-1338 CVE-2021-37137 netty-codec: SnappyFrameDecoder doesn’t restrict chunk length and may unnecessarily buffer skippable chunks
QUARKUS-1337 CVE-2021-37136 netty-codec: Bzip2Decoder doesn’t allow setting size restrictions for decompressed data
QUARKUS-1288 CVE-2021-37714 jsoup: Crafted input can cause the jsoup HTML and XML parser to get stuck
QUARKUS-1059 CVE-2021-28170 jakarta.el: ELParserTokenManager enables invalid EL expressions to be evaluate

10.2. Resolved issues

QUARKUS-1750 No license information for some RHBQ 2.2.5 artifacts
QUARKUS-1706 Old version of Quarkus RHBQ on code.quarkus PSI page
QUARKUS-1702 Inconsistent Netty artifacts in RHBQ 2.2.5 distributive
QUARKUS-1624 Bump jackson-bom from 2.12.4 to 2.12.5
QUARKUS-1623 Bump Netty to 4.1.69.Final
QUARKUS-1622 More efficient platform version and BOM import selection algorithm for a given set of extensions
QUARKUS-1621 Upgrade Jackson to 2.12.6
QUARKUS-1620 Bump log4j-api from 2.16.0 to 2.17.0 in /bom/application
QUARKUS-1611 Enforce order of arguments passed to native-image in container builds
QUARKUS-1610 Update Log4j 2 API to 2.15.0 - 2.2
QUARKUS-1609 Bump log4j-api from 2.15.0 to 2.16.0
QUARKUS-1608 Ban Logback dependencies from the build
QUARKUS-1607 Move 2.2 CI from JDK 16 to JDK 17
QUARKUS-1606 Update to Vert.x 4.1.7
QUARKUS-1591 Fix native-image arguments generation for native-sources package type
QUARKUS-1587 Add characterEscapeHandler TypedXmlWriter xml also support and fix separator jaxbindex
QUARKUS-1586 Run reactive rest client on Vertx same context
QUARKUS-1585 Re-enable single parsing of compiler graphs in native-image
QUARKUS-1584 Make @TestSecurity work with unannotated JAX-RS endpoints security feature
QUARKUS-1583 Trim container-image configuration values
QUARKUS-1582 Fixes related to Kotlin JVM target
QUARKUS-1581 Bump mongo-client.version from 4.3.1 to 4.3.2
QUARKUS-1580 Fix Multiple Hibernate ORM DevUI entries
QUARKUS-1579 Mark the uber-jar as a multi-release jar if META-INF/versions/ exists in the generated jar
QUARKUS-1578 Capture histogram data if it is configured for long task timers
QUARKUS-1577 GradleProjectBuildFile.getDependencies() must return direct dependencies instead of all of them
QUARKUS-1576 CLI: change rendering of nested subcommands in Help
QUARKUS-1575 Improve the kubernetes-config doc
QUARKUS-1574 Loosen restriction on casing of the Accept header
QUARKUS-1573 Use quarkus-gradle-plugin.version property in the JSON metadata template to represent the version of the Gradle plug-in
QUARKUS-1572 CLI: make display of subcommands consistent
QUARKUS-1571 Make MpMetadata public
QUARKUS-1570 Make locating java for @QuarkusIntegrationTest more intelligent
QUARKUS-1569 Make failure count red
QUARKUS-1568 Rest Client Reactive: support PathParam from BeanParam
QUARKUS-1567 Fix NPE and proper filtering of 1.x platform descriptors
QUARKUS-1566 ArC bean resolution - handle qualifier default values correctly
QUARKUS-1565 RoleBinding is correctly labelled / annotated
QUARKUS-1564 Use proper wait time for jar and docker launch modes
QUARKUS-1563 Enable the Panache annotation processor in Gradle if it’s found on the classpath
QUARKUS-1562 Bump smallrye-jwt version to 3.3.0
QUARKUS-1561 Fix quarkus.http.host-enabled=false without domain socket
QUARKUS-1560 Remove tomcat-annotations-api from Jaeger
QUARKUS-1559 Take configured wait time into account in @QuarkusIntegrationTest for log file check
QUARKUS-1558 Enable failure instead of a warning if one of the requested catalogs cannot be resolved
QUARKUS-1557 Fix issue where RESTEasy Reactive kept incorrect media type state
QUARKUS-1556 Support BouncyCastle KeyFactorySpi in native mode
QUARKUS-1555 Update OidcTestSecurityIdentityAugmentorProducer to generate a single RSA key
QUARKUS-1554 Fix reflections registration of constructors used in serialization
QUARKUS-1553 Update SmallRye Config to 2.5.0
QUARKUS-1551 Fix Swagger UI doc issue
QUARKUS-1550 Avoid NPE on nameCache miss
QUARKUS-1549 Fix scheduler doc broken links
QUARKUS-1548 Add test resources directory to CP
QUARKUS-1542 Add GraalVM 21.3 compatibility support for resource registration
QUARKUS-1541 Fix link to MicroProfile extension guide in the extension metadata
QUARKUS-1540 Do not enable basic auth as a fallback if it has been disabled
QUARKUS-1539 Deployment performance improvement
QUARKUS-1538 Fix issue with default beans resolution
QUARKUS-1537 Correct handling of empty GraphQL requests
QUARKUS-1536 Use only objcopy in Linux environments
QUARKUS-1535 Skip instrumentation check if disabled
QUARKUS-1534 Resilient enum for extension metadata and remove 'code' tag from resteasy-reactive-xxx
QUARKUS-1533 Replace websockets example by extension codestart in java & kotlin
QUARKUS-1532 Fix gdb debugging with GraalVM/Mandrel >=21.1
QUARKUS-1531 Micrometer: ignore null suppliers
QUARKUS-1530 Update SmallRye Config to 2.5.1
QUARKUS-1529 Fix misleading exception message on @Transactional(Transactional.TxType.NEVER)
QUARKUS-1528 Swap put and post methods
QUARKUS-1527 Add class information on exception
QUARKUS-1526 Handle dependency constraint in gradle conditional dependency resolution
QUARKUS-1525 Fix quarkus.native.debug-build-process
QUARKUS-1524 gradlew.bat/mvnw.bat must not be executable
QUARKUS-1523 Qute type-safe validation fix
QUARKUS-1522 Exclude javax.xml.bind:jaxb-api from the quarkus-bom
QUARKUS-1521 Fix serialization of Spring Data JPA Page in native mode
QUARKUS-1520 SmallRye Health codestart
QUARKUS-1519 Drop GraalVM / Mandrel 20.3 and 21.1 support
QUARKUS-1518 Exclude JUnit 4 from the quarkus-bom
QUARKUS-1517 Fix Micrometer unremovable bean handling
QUARKUS-1516 Upgrade to Hibernate ORM 5.5.8.Final - 2.2
QUARKUS-1515 DeploymentDependencySelector equals and hashCode impl
QUARKUS-1514 Update to GraalVM 21.3
QUARKUS-1513 Disable single parsing of compiler graphs by default
QUARKUS-1512 Regenerate truststore for self-signed certificate case
QUARKUS-1511 Update to Vert.x 4.1.6
QUARKUS-1504 Update tools provided Dockerfiles to use RHEL 8.5
QUARKUS-1351 JPA authorization fails in native mode in 2.2
QUARKUS-1350 Upgrade to Hibernate ORM 5.5.8.Final
QUARKUS-1340 Quarkus Maven Plug-in Dependency Tree is not resolving the versions correctly
QUARKUS-1336 Quarkus Operator SDK is not compatible with RHBQ 2.2
QUARKUS-1302 OpenShift: Update for deployments to OCP 3.11 that stopped working and OCP 4.x random failures
QUARKUS-1286 Config property is not found when in ForkJoin common Pool thread #20067
QUARKUS-1268 quarkus.log.min-level does not overwrite quarkus.log.level
QUARKUS-1256 Correct Gradle plug-in version in the metadata and in created projects
QUARKUS-1224 Fix RESTEasy Reactive @NoCache unexpected behavior
QUARKUS-1100 Quarkus CLI installation mechanism
QUARKUS-1097 CLI qs to support native executable building using containers
QUARKUS-1087 Implement Apicurio dev service
QUARKUS-1086 Implement Apicurio registry extension
QUARKUS-1073 Quarkus CLI support for registry / composable stream poms
QUARKUS-1072 Quarkus build and Dev for uniform access to common build tasks no matter the underlying build system
QUARKUS-1071 Quarkus create command for maven/gradle/jbang
QUARKUS-1027 OpenShift Service Binding - Technology preview
QUARKUS-960 Improved getting started experience with CLI
QUARKUS-728 Add support for OpenJDK 17
QUARKUS-719 Vertx PgPool lost connection unexpectedly

11. Advisories related to this release

The following advisory has been issued to document enhancements, bugfixes, and Common Vulnerabilities and Exposures (CVEs) fixes included in this release:

Revised on 2022-03-02 14:36:48 UTC

Legal Notices for Trademarks

Topics included in this guide

OpenJDK 11 and OpenJDK 17 OpenShift images support multiple architectures

Quick Links

Help

Site Info

Related Sites

Systems Status

About

Red Hat legal and privacy links

Red Hat legal and privacy links