Chapter 1. Release Notes for Red Hat build of Quarkus 2.2

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.

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

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.

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):

  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.

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:

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

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

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.

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:

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

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.

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

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

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

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

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

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

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.

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:

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

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:

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.

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.

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:

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.

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.

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

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:

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

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.

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

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.

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.

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.

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

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.

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 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:

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.

quarkus.quartz.start-mode=forced

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

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.

quarkus.quartz.store-type=jdbc-cmt

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.

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.

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:

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.

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.

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.

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.

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.

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

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

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:

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.

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.

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;
}

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.

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

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

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:

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

Red Hat provides development support for the following Red Hat build of Quarkus features, plugins, 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).

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)

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.

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

For more information about this issue, see QUARKUS-1457

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

fips-mode-setup --check

FIPS mode is enabled.

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

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

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.

This issue has been observed in the following software:

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