Release Notes for Red Hat build of Quarkus 2.7

Guide
  • Red Hat build of Quarkus 2.7
  • Updated 27 July 2022
  • Published 18 May 2022

Release Notes for Red Hat build of Quarkus 2.7

Guide
Red Hat build of Quarkus 2.7
  • Updated 27 July 2022
  • Published 18 May 2022

These release notes provide information about new features, notable technical changes, features in technology preview, bug fixes, known issues, and related advisories for Red Hat build of Quarkus 2.7. Information about upgrading and backward compatibility is also provided to help you transition from an earlier release.

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. About 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, Eclipse Vert.x, Apache Camel, Apache Kafka, Hibernate ORM (JPA), and RESTEasy (JAX-RS).

As a developer, you can choose the Java frameworks you want for your Java applications, which you can run in Java Virtual Machine (JVM) mode or compile and run in native mode. Quarkus provides a container-first approach to building Java applications. The container-first approach facilitates the containerization and efficient execution of microservices and functions. For this reason, Quarkus applications have a smaller memory footprint and faster startup times.

In addition, Quarkus optimizes the application development process with capabilities, such as unified configuration, automatic provisioning of unconfigured services, live coding, and continuous testing that allows you to get instant feedback on your code changes.

For information about the differences between the Quarkus community version and Red Hat build of Quarkus, see Differences between the Quarkus community version and Red Hat build of Quarkus.

2. Differences between the Quarkus community version and Red Hat build of Quarkus

As an application developer, you can access two different versions of Quarkus: the Quarkus community version and the productized version, Red Hat build of Quarkus (RHBQ).

The following table describes the differences between the Quarkus community version and RHBQ.

Feature Quarkus community version Red Hat build of Quarkus version Description

Access to the latest community features

Yes

No

With the Quarkus community version, you can access the latest feature developments.

Red Hat does not release RHBQ to correspond with every version that the community releases. The cadence of RHBQ feature releases is approximately every six months.

Enterprise support from Red Hat

No

Yes

Red Hat provides enterprise support for RHBQ only. To report issues about the Quarkus community version, see quarkusio/quarkus - Issues.

Access to long term support

No

Yes

Each feature release of RHBQ is fully supported for approximately one year up until the next feature release. When a feature release is superseded by a new version, Red Hat continues to provide a further six months of maintenance support. For more information, see Support and compatibility.

Common Vulnerabilities and Exposures (CVE) fixes and bug fixes backported to earlier releases

No

Yes

With RHBQ, selected CVE fixes and bug fixes are regularly backported to supported streams. In the Quarkus community version, CVEs, and bug fixes are typically made available in the latest release only.

Tested and verified with Red Hat OpenShift Container Platform and Red Hat Enterprise Linux (RHEL)

No

Yes

RHBQ is built, tested, and verified with Red Hat OpenShift Container Platform and RHEL. Red Hat provides both production and development support for supported configurations and tested integrations according to your subscription agreement. For more information, see Red Hat build of Quarkus Supported Configurations.

Built from source using secure build systems

No

Yes

In RHBQ, the core platform and all supported extensions are provided by Red Hat using secure software delivery, which means that they are built from source, scanned for security issues, and with verified licence usage.

Access to support for JDK and GraalVM Mandrel distribution

No

Yes

RHBQ supports certified OpenJDK builds and certified native executable builders. See admonition below. For more information, see Red Hat build of Quarkus Supported Configurations.

Red Hat build of Quarkus supports the building of native Linux executables by using the Red Hat build of Quarkus Native builder, which is a productized distribution of Mandrel. For more information, see Compiling your Quarkus applications to native executables. Building native executables by using Oracle GraalVM Community Edition (CE), Mandrel community edition, or any other distributions of GraalVM is not supported for Red Hat build of Quarkus.

3. New features, enhancements, and technical changes

This section provides an overview of the new features, enhancements, and technical changes introduced in Red Hat build of Quarkus 2.7.

3.1. Cloud

3.1.1. Support for Service Binding CR

Red Hat build of Quarkus 2.7 supports the generation of Service Binding custom resources (CR), which means you can now define custom service bindings by using Red Hat build of Quarkus configuration.

For more information, see the new Service Binding guide.

3.2. Core

3.2.1. Increased support for Java 17 in JVM mode

Red Hat build of Quarkus 2.7 includes improved developer tools for using Java 17. With these improved developer tools, you can now generate projects based on Java 17 without manually configuring the version. Quarkus 2.7 also includes a Technology Preview for Java 17 in native mode.

By default, the code.quarkus.redhat.com starter code targets Java 11. If you want an application to target Java 17, ensure to set the expected Java version in the Configure your application section of https://code.quarkus.redhat.com. This is especially relevant when you are building applications for containers because the base images differ depending on the Java versions. For more information, see Deploying your Quarkus applications to OpenShift.

For more information about supported Java and OpenJDK versions, log in to our Customer Portal and see Red Hat build of Quarkus Supported Configurations.

3.3. Data

3.3.1. Dev Services for Infinispan

Red Hat build of Quarkus 2.7 supports Dev Services for the Infinispan in-memory data grid through the quarkus-infinispan-client extension. Now you no longer need to set up and configure a local Infinispan server to test your applications.

When your Quarkus application includes the quarkus-infinispan-client extension, in either dev or test mode, Quarkus automatically starts an Infinispan server instance and configures your application. If Docker is detected, the container starts, and the connection to the server is automatically stabilized.

You can configure the quarkus-infinispan-client through the following application.properties file attributes:

Attribute Description Default

quarkus.infinispan-client.devservices.enabled

Use to enable or disable Dev Services for Infinispan. By default, using the extension enables Dev Services without the need for configuration. To disable the Dev Service for Infinispan, set the value to false.

True

quarkus.infinispan-client.server-list

Optional: Use only in production environments (%prod profile) if you need to explicitly configure one or more Infinispan servers or disable Dev Services for a specific server.

No values set

For more information about Dev Services, see the following resources:

3.3.2. Hibernate Search integration

Red Hat build of Quarkus now integrates the Hibernate Search 6.1 component (hibernate-search-orm-elasticsearch) providing powerful indexing and full-text search capabilities to your Quarkus application.

Hibernate Search integrates with Hibernate Object Relational Mapper (ORM) to automatically extract data from entities into remote indexes.

Hibernate Search also provides a Java API, which you can use to run search queries against those indexes and retrieve the resulting managed entities.

Through the hibernate-search-orm-elasticsearch extension, Red Hat build of Quarkus 2.7 provides support for the following remote indexes:

  • OpenSearch

  • Elasticsearch

Quarkus also builds the Hibernate Search metamodel at compilation time, enabling your application to start and run faster.

You can use the hibernate-search-orm-elasticsearch extension with RESTEasy Classic and RESTEasy Reactive.

Integration with Hibernate Reactive is not supported.

For more information about the hibernate-search-orm-elasticsearch extension, see the Hibernate Search guide.

3.3.3. JPA entity listeners

Red Hat build of Quarkus 2.7 now supports Java Persistence API (JPA) entity listeners for JVM and native modes. JPA entity listeners enable you to receive notifications about a particular lifecycle event of an entity.

Using Quarkus, you can now create an entity listener with an annotated callback method for any of the following entity lifecycle events:

  • @PrePersist

  • @PostPersist

  • @PostLoad

  • @PreUpdate

  • @PostUpdate

  • @PreRemove

  • @PostRemove

For more information about JPA callback annotations, see the 'Interceptors and events' section of the Hibernate ORM user guide.

3.3.4. Programmatic API for caching

Red Hat build of Quarkus 2.7 enhances the existing annotations support for caching by introducing a programmatic API, which you can use to store, retrieve, or delete values from any cache that is declared by using the annotations API.

  • All operations from the programmatic API are non-blocking and rely on Mutiny.

  • To use the programmatic API to access cached data, you must first retrieve an instance of io.quarkus.cache.Cache.

  • You cannot use the programmatic API to create a new cache. You can use the programmatic API only to access a cache that was created with the annotations API.

For more information, see the 'Caching using the programmatic API' section of the Application Data Caching guide.

3.3.5. Support for Hibernate ORM interceptors

Red Hat build of Quarkus 2.7 introduces support for Hibernate Object Relational Mapper (ORM) interceptors, which you can use to enable advanced auditing within your applications.

The org.hibernate.Interceptor interface provides callbacks from the session, enabling your Red Hat build of Quarkus application to inspect and manipulate properties of a persistent object before it is saved, updated, deleted, or loaded.

To ensure that Red Hat build of Quarkus automatically configures Hibernate ORM to use the interceptor, you can annotate org.hibernate.Interceptor with the @PersistenceUnitExtension qualifier. For named persistence units, use @PersistenceUnitExtension("nameOfYourPU").

For more information, see Using Hibernate ORM and JPA.

3.3.6. Hibernate ORM SQL load script enhancements

In Red Hat build of Quarkus 2.7, the Hibernate Object Relational Mapper (ORM) is enhanced to allow multiple SQL files in the SQL load script. Now, you can specify multiple comma-separated SQL files in the quarkus.hibernate-orm.sql-load-script configuration property, which runs when Hibernate ORM starts.

You can use an SQL load script to perform various actions when creating database tables from scratch. For example, with the SQL load script, you can run CREATE DATABASE and CREATE TABLE actions or run database update actions, such as INSERT and UPDATE. The SQL load script runs when the Quarkus application starts.

Example: quarkus.hibernate-orm.sql-load-script=import-1.sql,import-2.sql

3.3.7. Support for Oracle data sources

You can now use Oracle Database as a data source for your applications. Red Hat build of Quarkus 2.7 introduces support for the Oracle JDBC driver extension, quarkus-jdbc-oracle, which you can use while developing applications in JVM and native modes.

Red Hat build of Quarkus 2.7 now also provides Dev Services for Oracle Database, which means that you can start your Oracle database automatically in dev and test modes. These Red Hat build of Quarkus Dev Services use a container image of Oracle Database Express Edition (XE).

3.3.8. Reactive Microsoft SQL Server client encryption

In Red Hat build of Quarkus 2.7, the Reactive Microsoft SQL Server client now supports SSL/TLS encryption.

You can now secure connections from your Quarkus applications to an SSL/TLS enabled Microsoft SQL Server. The Reactive client supports the following Microsoft SQL Server encryption levels: none, login packet only, and entire connection.

Use the following client encryption configuration properties of Quarkus to enable SSL/TLS encryption when connecting to a Microsoft SQL Server instance.

Table 1. Reactive Microsoft SQL Server client encryption properties
Quarkus Property Type Description Default

quarkus.datasource.reactive.mssql.ssl

Boolean

Determines whether SSL/TLS is enabled for the configuration properties that are fixed at build time.

False

quarkus.datasource."datasource-name".reactive.mssql.ssl

Boolean

Determines whether SSL/TLS encryption is enabled for other specified data sources. Can be overridden at runtime.

False

When your Reactive Microsoft SQL Server client connects, the encryption level is negotiated through the combined configuration of the Quarkus Reactive Microsoft SQL Server client encryption properties and the Microsoft SQL Server SSL support state, as outlined in the following table:

Table 2. Levels of encryption support

SSL Server→

Quarkus Client ↓

Encryption not supported

Encryption supported

Encryption required

SSL/TLS = true

Client terminates connection

Entire connection encrypted

Entire connection encrypted

SSL/TLS = false

No encryption

Login packet only

Entire connection encrypted

The encryption negotiation fails when you enable SSL/TLS in the Quarkus client and the Microsoft SQL Server instance that the client is connecting to does not support encryption. In this case, the client terminates the connection.

3.4. Installation and upgrade

3.4.1. Hibernate ORM upgraded to version 5.6.5

In Red Hat build of Quarkus 2.7, Hibernate Object Relational Mapper (ORM) is upgraded to version 5.6.5, which includes feature enhancements and several fixes.

For more information about the Hibernate ORM updates, see the New features, enhancements, and technical changes and Changes that affect backwards compatibility sections.

3.4.2. Quarkus Apache Kafka components upgraded to version 3.1.0

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

3.4.3. Quarkus SmallRye reactive messaging components upgraded to version 3.13.0

In Red Hat build of Quarkus 2.7, SmallRye reactive messaging components are upgraded to version 3.13.0 to interact with Apache Kafka. You can upgrade the SmallRye reactive messaging components and take advantage of the additional features, such as:

  • Improved functionality with message converters on injected channels, Apache Kafka Consumer streams, failure handlers for Apache Kafka serialization, and merged configuration implementation

  • Upgraded the components to Vert.x 4.2.1, Vert.x Mutiny Bindings 2.15.0, and vertx-stack-depchain 4.1.5

  • Reduced the log levels for Apache Kafka messages

  • Apache Kafka connector option to consume messages in batches

  • Enabled channels listing inside the KafkaClientService component

  • Updated MicroProfile reactive messaging to version 2.0.1

3.5. Logging

3.5.1. Simplified logging with Panache

Red Hat build of Quarkus 2.7 provides simplified logging, which is sometimes referred to as logging with Panache. When you are developing applications, you no longer need to declare a logger in your class or inject it. Instead, you can call static methods from the io.quarkus.logging.Log class. Quarkus automatically declares a logger in each class that uses the Log API and redirects the static method calls to this logger. Simplified logging is provided by default, so you do not need to configure or enable the feature.

Simplified logging with Panache works directly in Quarkus application classes and not in external dependencies therefore, you cannot use this logging feature in your external libraries. Static method calls on the Log class that are not processed by Quarkus at build time, throw an exception.

Example usage of the simplified logging API

Rather than declaring a logger field, use the simplified logging API, as shown in the following example.

package com.example;

import io.quarkus.logging.Log;

class MyService {
    public void doSomething() {
        Log.info("Simple!");
    }
}

The fully qualified name of the class is used as the logger category, so in the simplified logging API example, the logger category is com.example.MyService.

3.6. Messaging

3.6.1. Batch message processing on Quarkus Apache Kafka

Quarkus provides support for Apache Kafka through the SmallyRye reactive messaging framework. With this framework, you can send and receive messages by using the Apache Kafka connector component.

With Red Hat build of Quarkus 2.7, the Apache Kafka connector component is enhanced to enable batch processing of incoming messages, which means that the Quarkus application can receive and process multiple Apache Kafka messages at once. By processing messages in batches, you can write multiple messages to a database at the same time, thereby improving performance.

By default, incoming channels receive each Kafka message individually, however, in the background, the Kafka consumer client polls the broker continuously and receives the messages in batches. Quarkus 2.7 receives the batch of messages that is returned by the poll all at once.

You do not need to configure batch mode on your Quarkus application manually. Instead, if an incoming method receives a Kafka parameter type that is compatible with batch mode, the Quarkus application detects this and configures it for you.

Batches are not formed by grouping messages according to a specific criteria. Instead, the Kafka consumer groups messages according to the polled records.

For more information about how you can interact with Kafka by using Quarkus, see the Apache Kafka reference guide.

3.7. Scalability and performance

3.7.1. UPX compression for native executables

The Ultimate Packer for eXecutables (UPX) is used as a compression tool to reduce the size of executables.

In Red Hat build of Quarkus 2.7, UPX compression is for development use only and not supported in a production environment.

UPX compression increases the build time, when you use high-compression levels and increases the memory usage of the application.

For more information about the UPX compression, see Compress Native Executables with UPX.

3.7.2. Base images for native executables

The following base images are used to make the containerization of native executables easier by providing the requirements to run these native executables:

  • The registry.access.redhat.com/ubi8/ubi-minimal:8.5 image provides a complete image with a package manager and a shell. You can use this image if the image size is not the primary constraint.

  • The quay.io/quarkus/quarkus-micro-image:1.0 image is a smaller base image, providing the native executable requirements, such as glibc, libstdc++, and zlib.

    Also, both base images support UPX compressed executables.

In Red Hat build of Quarkus 2.7, the quay.io/quarkus/quarkus-micro-image:1.0 image is for development use only and not supported in a production environment.

For more information about the base images, see Quarkus base runtime image.

3.7.3. Ability to test multi-module projects

In Red Hat build of Quarkus 2.7, you can now perform continuous testing for tests available in any module of a project in dev mode. To perform continuous testing for tests available in a particular module that is running from quarkus:dev mode, you can set the following property to true in application.properties file:

quarkus-core_quarkus.test.only-test-application-module=true

To control which modules are tested, you can use quarkus.test.include-module-pattern and quarkus.test.exclude-module-pattern properties.

3.8. Web

3.8.1. REST Client Reactive enhancements

The REST Client Reactive component that is integrated with Red Hat build of Quarkus 2.7 is improved with the following enhancements:

  • Configuration: In addition to the standard MicroProfile configuration properties, you can now configure your clients with properties consistent with other Quarkus extensions, namely properties with the quarkus.rest-client prefix.

  • Dev UI: You can view a list of available client interfaces from the Quarkus Dev UI. You can also open available client interfaces within your IDE.

  • Multipart messages: You can send multipart/form-data requests and parse multipart/form-data responses.

  • ParamConverter: You can register ParamConverter for clients and servers. In previous versions, you could only register ParamConverter for servers.

  • Proxy support: The integrated REST Client Reactive component of Quarkus supports sending requests through a proxy. The following enhancements to the proxy are also introduced:

    • Proxy authentication is supported.

    • You can configure local proxy settings specific to a client in an application.

    • You configure global proxy settings so that all clients in an application observe and propagate settings from a global configuration.

    • You can configure your application to observe and propagate proxy settings from your JVM properties configuration.

  • Recursive sub-resources: Quarkus supports recursive sub-resources so you can build deeper hierarchies of sub-resources.

4. Support and compatibility

You can find detailed information about the supported configurations and artifacts that are compatible with Red Hat build of Quarkus 2.7 and the high-level support life cycle policy on the Red Hat Customer Support portal as follows:

4.1. Product updates and support life cycle policy

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

Red Hat does not release a productized version of Quarkus for every version the community releases. The cadence of the Red Hat build of Quarkus feature releases is about every six months.

Red Hat build of Quarkus provides full support for a feature release right up until the release of a subsequent version. When a feature release is superseded by a new version, Red Hat continues to provide a further six months of maintenance support for the release, as outlined in the following support life cycle chart [Fig. 1].

Diagram that demonstrates the feature release cadence and support life cycle of Red Hat build of Quarkus
Figure 1. Feature release cadence and support life cycle of Red Hat build of Quarkus

During the full support phase and maintenance support phase of a release, Red Hat also provides 'service-pack (SP)' updates and 'micro' releases to fix bugs and Common Vulnerabilities and Exposures (CVE).

New features in subsequent feature releases of Red Hat build of Quarkus can introduce enhancements, innovations, and changes to dependencies in the underlying technologies or platforms. For a detailed summary of what is new or changed in a successive feature release, see New features, enhancements, and technical changes.

While most of the features of Red Hat build of Quarkus continue to work as expected after you upgrade to the latest release, there might be some specific scenarios where you need to change your existing applications or do some extra configuration to your environment or dependencies. Therefore, before upgrading Red Hat build of Quarkus to the latest release, always review the Changes that affect backwards compatibility and Deprecated components and features sections of the release notes.

4.2. Tested and verified environments

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

Please note the Tested and Supported columns for each CPU architecture. For versions in the following table, the deployment environments of which are not tested, see this Support of Red Hat Middleware products and components on Red Hat OpenShift knowledge-based article to get the information about their support status.

Table 3. Supported deployment environments for Red Hat build of Quarkus 2.7 on Red Hat OpenShift Container Platform and Red Hat Enterprise Linux

Platform

Architecture

Container Image / JVM

Tested

Supported

OpenShift Container Platform 3.11

AMD64 and Intel 64 (x86_64)

Red Hat OpenJDK 11 & Red Hat OpenJDK 17

No

Yes - See the Support article

OpenShift Container Platform 4.6

AMD64 and Intel 64 (x86_64)

Red Hat OpenJDK 11 & Red Hat OpenJDK 17

Yes

Yes

OpenShift Container Platform 4.6

IBM Z (s390x)

Red Hat OpenJDK 11

Yes

Yes

OpenShift Container Platform 4.6

IBM Power (ppc64le)

Red Hat OpenJDK 11

Yes

Yes

OpenShift Container Platform 4.7

AMD64 and Intel 64 (x86_64)

Red Hat OpenJDK 11 & Red Hat OpenJDK 17

No

Yes - See the Support article

OpenShift Container Platform 4.7

IBM Z (s390x)

Red Hat OpenJDK 11

No

Yes - See the Support article

OpenShift Container Platform 4.7

IBM Power (ppc64le)

Red Hat OpenJDK 11

No

Yes - See the Support article

OpenShift Container Platform 4.8

AMD64 and Intel 64 (x86_64)

Red Hat OpenJDK 11 & Red Hat OpenJDK 17

No

Yes - See the Support article

OpenShift Container Platform 4.8

IBM Z (s390x)

Red Hat OpenJDK 11

No

Yes - See the Support article

OpenShift Container Platform 4.8

IBM Power (ppc64le)

Red Hat OpenJDK 11

No

Yes - See the Support article

OpenShift Container Platform 4.9

AMD64 and Intel 64 (x86_64)

Red Hat OpenJDK 11 & Red Hat OpenJDK 17

No

Yes - See the Support article

OpenShift Container Platform 4.9

IBM Z (s390x)

Red Hat OpenJDK 11

No

Yes - See the Support article

OpenShift Container Platform 4.9

IBM Power (ppc64le)

Red Hat OpenJDK 11

No

Yes - See the Support article

OpenShift Container Platform 4.10

AMD64 and Intel 64 (x86_64)

Red Hat OpenJDK 11 & Red Hat OpenJDK 17

Yes

Yes

OpenShift Container Platform 4.10

IBM Z (s390x)

Red Hat OpenJDK 11

Yes

Yes

OpenShift Container Platform 4.10

IBM Power (ppc64le)

Red Hat OpenJDK 11

Yes

Yes

Red Hat Enterprise Linux 8

AMD64 and Intel 64 (x86_64)

OpenJDK 11.x & OpenJDK 17.x

Yes

Yes

4.3. Development support

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

Features
  • Continuous Testing

  • Dev Services

  • Dev UI

  • Local development mode

  • Remote development mode

Plug-ins
  • Maven Protocol Buffers Plugin

5. Deprecated components and features

The components and features listed in this section are deprecated with Red Hat build of Quarkus 2.7. They are included and supported in this release, however, no enhancements will be made to these components and features and they might be removed in the future.

For a list of the components and features that are deprecated in this release, log in to the Red Hat Customer Portal and view the Red Hat build of Quarkus Component Details page.

5.1. Removal of deprecated methods and classes in Mutiny

The following Mutiny methods and classes have been removed:

  • method MultiCollect<T> Multi<T>::collectItems()

  • method MultiGroup<T> Multi<T>::groupItems()

  • method MultiTransform<T> Multi<T>::transform()

  • method Uni<T> Uni<T>::cache()

  • method Multi<T> MultiOverflow<T>::drop(Consumer<T>)

  • class MultiTransform<T>

  • method MultiTransform<T> AbstractMulti<T>::transform() @ MultiGlobalSpy<T>

  • method MultiTransform<T> AbstractMulti<T>::transform() @ MultiOnCancellationSpy<T>

  • method MultiTransform<T> AbstractMulti<T>::transform() @ MultiOnCompletionSpy<T>

  • method MultiTransform<T> AbstractMulti<T>::transform() @ MultiOnFailureSpy<T>

  • method MultiTransform<T> AbstractMulti<T>::transform() @ MultiOnItemSpy<T>

  • method MultiTransform<T> AbstractMulti<T>::transform() @ MultiOnOverflowSpy<T>

  • method MultiTransform<T> AbstractMulti<T>::transform() @ MultiOnRequestSpy<T>

  • method MultiTransform<T> AbstractMulti<T>::transform() @ MultiOnSubscribeSpy<T>

  • method MultiTransform<T> AbstractMulti<T>::transform() @ MultiOnTerminationSpy<T>

6. Technology Previews

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

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 about Red Hat Technology Preview features, see Technology Preview Features Scope.

6.1. Support for Hibernate Reactive

In Red Hat build of Quarkus 2.7, Hibernate Reactive is provided as a Technology Preview feature.

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

6.2. Support for Java 17 in native mode

In Quarkus 2.7, building native executables by using Java 17 is provided as a Technology Preview feature. To build native executables for production deployments, use Java 11.

6.3. Technology Preview extensions and dependencies

For a list of extensions and dependencies available as Technology Preview in Red Hat build of Quarkus 2.7, 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

7. Changes that affect backwards compatibility

This section describes changes that affect the backwards compatibility of Red Hat build of Quarkus 2.7 with applications based on earlier releases.

You must address these changes when upgrading your applications to Red Hat build of Quarkus 2.7 to ensure that your applications continue to function after the upgrade.

7.1. quarkus-vertx-web is now quarkus-reactive-routes

The artifact quarkus-vertx-web is renamed as quarkus-reactive-routes. If you use quarkus-vertx-web as the artifact name, Red Hat build of Quarkus 2.7 displays a warning message while building your application. Therefore, you can switch to the new artifact coordinates, io.quarkus:quarkus-reactive-routes.

7.2. A change in RESTEasy Reactive return type on a JAX-RS method for multipart responses

A backward-incompatible change in RESTEasy Reactive was incorporated between product versions 2.7.5 and 2.7.6. This change doesn’t allow the use of javax.ws.rs.core.Response as a return type on a JAX-RS method for multipart responses, and org.jboss.resteasy.reactive.RestResponse must be used instead.

7.3. The quarkus-spring-web extension decoupled from RESTEasy Classic

In Red Hat build of Quarkus 2.7, the quarkus-spring-web extension works with both RESTEasy Classic, which is the quarkus-resteasy extension, and RESTEasy Reactive, which is the quarkus-resteasy-reactive extension. quarkus-spring-web no longer has a hard dependency on quarkus-resteasy-jackson. If you are using quarkus-spring-web, explicitly add quarkus-resteasy-jackson or quarkus-resteasy-reactive-jackson to your applications.

7.4. The rest-data-panache extension decoupled from RESTEasy Classic

In Red Hat build of Quarkus 2.7, the extensions quarkus-hibernate-orm-rest-data-panache, quarkus-spring-data-rest, and quarkus-mongodb-rest-data-panache can work with both RESTEasy Classic, which is the quarkus-resteasy extension and RESTEasy Reactive, which is the quarkus-resteasy-reactive extension. rest-data-panache no longer has a hard dependency on quarkus-resteasy. If you are using the panache extensions, explicitly add quarkus-resteasy or quarkus-resteasy-reactive to your applications.

7.5. Hibernate ORM default database creation mode changed when Dev Services are in use

In Red Hat build of Quarkus 2.7, when Dev Services are in use and no other extensions that manage the schema are present, the default database creation mode for Hibernate Object/Relational Mapping (Hibernate ORM) is drop-and-create. This change ensures that Dev Services always start from a clean state.

This change only affects Dev Services. When Dev Services are not in use, the default database creation mode continues to be none, like in the previous versions of Red Hat build of Quarkus.

7.6. JNDI is disabled by default

In Red Hat build of Quarkus 2.7, the Java Naming and Directory Interface (JNDI) is disabled by default. To enable the JNDI, you can use the quarkus.naming.enable-jndi=true property.

7.7. gRPC - Client Interceptors require @GlobalInterceptor annotation

Global gRPC client interceptors must be annotated with @io.quarkus.grpc.GlobalInterceptor since version 2.7. Before Quarkus 2.7, all the CDI beans implementing io.grpc.ClientInterceptor were considered as global interceptors, i.e., applied to all injected gRPC clients. Since 2.7, it is possible to make a client-specific interceptor by annotating the injection point of a gRPC client with the @io.quarkus.grpc.RegisterClientInterceptor annotation.

7.8. gRPC server interceptors require @GlobalInterceptor annotation

Starting from Red Hat build of Quarkus 2.7, you must annotate the global server interceptors using the @io.quarkus.grpc.GlobalInterceptor annotation.

The annotation for the global server and client interceptors is the same, but the interfaces implemented by the interceptors are different.

Also, in Red Hat build of Quarkus 2.7, you can implement a non-global interceptor and add it to a gRPC service in the implementation class. For example, you can use the following code to implement your interceptor:

Example implementation of an interceptor
@ApplicationScoped
public class MyInterceptor implements ServerInterceptor {

@Override
public <ReqT, RespT> ServerCall.Listener<ReqT> interceptCall(ServerCall<ReqT, RespT> serverCall,
Metadata metadata, ServerCallHandler<ReqT, RespT> serverCallHandler)

{ // ... }
}

After implementing your interceptor, you can use the io.quarkus.grpc.RegisterInterceptor annotation in the service implementation as shown in the following example:

Example service implementation
@GrpcService
@RegisterInterceptor(MyInterceptor.class)
public class MyServiceImpl implements MyService

{ // ... }

7.9. gRPC - Metrics are now handled by Micrometer

gRPC metrics are now handled by the quarkus-micrometer extension. gRPC server and client metrics are automatically enabled when your application depends on this extension. If you do not want to collect these metrics, disable them using:

quarkus.micrometer.binder.grpc-client.enabled=false
quarkus.micrometer.binder.grpc-server.enabled=false

The quarkus.grpc.metrics.enabled property has no effect anymore.

7.10. HTTP endpoints with gRPC services using extensions

Starting from Red Hat build of Quarkus 2.7, quarkus-grpc does not pull quarkus-http extension. Therefore, to serve the HTTP endpoints along with gRPC services, you can add any of the following extensions to your Quarkus project:

  • io.quarkus:quarkus-http

  • io.quarkus:quarkus-resteasy

  • io.quarkus:quarkus-resteasy-reactive

In case you are already using one of the previous extensions in your Quarkus project, then no actions are required.

7.11. Reactive Routes - Changes in how produces work with Multi

The produces attribute of the @Route annotation was only used for content negotiation. Starting with Quarkus 2.7, it is also used to indicate how objects produced by the Multi need to be serialized in the HTTP response.

When a route returns a Multi<T>, it is possible to:

  • send the item one by one, without any modification (raw stream)

  • wrap the Multi as a JSON Array, where each item is sent one by one

  • produce a server-sent-event stream

  • produce JSON (also named ND-JSON) stream

Before Quarkus 2.7, to express the three last possibilities, you had to wrap the produced Multi using ReactiveRoutes.asJsonArray, ReactiveRoutes.asEventStream, and ReactiveRoutes.asJsonStream. Unfortunately, this approach does not work when Quarkus security is enabled.

To workaround that problem, in Quarkus 2.7, indicate the serialization you need using the produces attribute of @Route. If the first value of the produced array is application/json, text/event-stream, application/x-ndjson or application/stream+json, the associated serialization is used.

So, instead of:

  • returning ReactiveRoutes.asJsonArray(multi), return multi directly and set produces="application/json"

  • returning ReactiveRoutes.asEventStream(multi), return multi directly and set produces="text/event-stream"

  • returning ReactiveRoutes.asJsonStream(multi), return multi directly and set produces="application/x-ndjson"

7.12. Reactive Routes - Change of the JSON response format

The JSON response format produced when a constraint violation occurs was changed in an incompatible way. If a reactive route method parameter violates the rules defined by Bean Validation, then an HTTP 400 response is produced. If the request accepts the JSON payload, the response should follow the Problem format. However, before version 2.7, the produced JSON included an incorrect property: details. The payload now follows the format (the property is called detail).

7.13. Removal of deprecated methods from OIDC

OIDC TokenConfigResolver methods deprecated in 2.2, and TokenStateManager methods deprecated in 2.3 have now been removed. If any, it should have a minimal impact since only TokenConfigResolver and TokenStateManager methods returning Uni can work without blocking the IO thread. Therefore, they should be used in real-world applications.

7.14. Removal of extensions from Red Hat build of Quarkus

The following extensions are removed from Red Hat build of Quarkus 2.7 and moved to the Quarkiverse Hub repository:

  • Apache ActiveMQ Artemis

  • Quarkus Amazon Alexa

  • Quarkus Amazon Services, which includes the following set of extensions:

    • DynamoDB

    • Identity and Access Management (IAM)

    • Key Management Service (KMS)

    • S3

    • Secrets Manager

    • Simple Email Service (SES)

    • Simple Notification Service (SNS)

    • Simple Queue Service (SQS)

    • Systems Manager (SSM)

  • Quarkus Consul Config

  • Quarkus JGit

  • Quarkus JSch

  • Quarkus Logging Sentry

  • Quarkus Neo4j

  • Quarkus Reactive Messaging HTTP

  • Quarkus Apache Tika

  • Quarkus File Vault

For a list of extensions hosted in the Quarkiverse Hub, see Quarkiverse Hub.

7.15. Prefixes for iteration metadata inside a loop

In Red Hat build of Quarkus 2.7, you cannot directly use the keys to access the iteration metadata inside a loop. Instead, a prefix is used to avoid possible collisions with variables from the outer scope.

By default, the alias of an iterated element suffixed with an underscore is used as a prefix. For example, the hasNext key must be prefixed with it_ inside an {#each} section: {it_hasNext}. It must also be in the form of {item_hasNext} inside a {#for} section with the item element alias.

You can configure the prefix using either EngineBuilder.iterationMetadataPrefix() for standalone Qute or using the quarkus.qute.iteration-metadata-prefix configuration property in a Quarkus application. You can provide a custom string value or use one of the following special constants:

  • <alias_>: The alias of an iterated element suffixed with an underscore. This is the default prefix. For example, {item_hasNext}

  • <alias?>: The alias of an iterated element suffixed with a question mark. For example, {item?hasNext}

  • <none>: No prefix. This is the default behavior in the previous versions. For example, {hasNext}

7.16. Smallrye Reactive Messaging packages renamed

The following table shows the list of SmallRye Reactive Messaging packages in the smallrye-reactive-messaging-provider module that are renamed in Red Hat build of Quarkus 2.7:

Table 4. Renamed SmallRye Reactive Messaging packages
Old package name New package name

io.smallrye.reactive.messaging

io.smallrye.reactive.messaging.providers

io.smallrye.reactive.messaging.connectors

io.smallrye.reactive.messaging.providers.connectors

io.smallrye.reactive.messaging.extension

io.smallrye.reactive.messaging.providers.extension

io.smallrye.reactive.messaging.helpers

io.smallrye.reactive.messaging.providers.helpers

io.smallrye.reactive.messaging.i18n

io.smallrye.reactive.messaging.providers.i18n

io.smallrye.reactive.messaging.impl

io.smallrye.reactive.messaging.providers.impl

io.smallrye.reactive.messaging.metrics

io.smallrye.reactive.messaging.providers.metrics

io.smallrye.reactive.messaging.wiring

io.smallrye.reactive.messaging.providers.wiring

7.17. Aligning with Eclipse MicroProfile Config Specification

Based on the Eclipse MicroProfile Config Specification, ConfigProperties injection points that target already annotated org.eclipse.microprofile.config.inject.ConfigProperties beans needs to be annotated with the same qualifier too.

7.18. Hibernate ORM: SQLServer2016Dialect is now the default dialect for MSSQL databases

In Red Hat build of Quarkus 2.7, the default MSSQL dialect for Hibernate ORM is SQLServer2016Dialect. If you use Microsoft SQL Server 2012, set the configuration property quarkus.hibernate-orm.dialect to org.hibernate.dialect.SQLServer2012Dialect.

7.19. Narayana LRA extension requirements

In Red Hat build of Quarkus 2.7, for the quarkus-narayana-lra extension to work you need to implement a server JAX-RS and a REST Client. This means that you must have any one of the following dependencies in your Quarkus application:

  • The set of quarkus-resteasy-jackson and quarkus-rest-client

  • The set of quarkus-resteasy-reactive-jackson and quarkus-rest-client-reactive

7.20. Change in default key encryption algorithm for quarkus-smallrye-jwt-build

In Red Hat build of Quarkus 2.7, the default key encryption algorithm is changed in quarkus-smallrye-jwt-build from RSA-OAEP-256 to RSA-OAEP.

You can configure the RSA-OAEP-256 algorithm using the smallrye.jwt.new-token.key-encryption-algorithm property as shown in the following example:

smallrye.jwt.new-token.key-encryption-algorithm=RSA-OAEP-256

7.21. Default working directory changed in development mode

In Red Hat build of Quarkus 2.7, the default working directory in development mode is changed from the target directory to the project directory that you are currently working in.

If your Quarkus application is unable to resolve file paths to the current working directory, you might need to append target to the path of the file you want to access.

For example, for a project in the code-with-quarkus directory, the working directory in development mode is changed from code-with-quarkus/target to code-with-quarkus.

8. Fixes

Quarkus 2.7 provides increased stability and includes a number of fixes for issues that were identified in earlier releases.

8.1. Security fixes

8.1.1. Quarkus 2.7.6

  • QUARKUS-2076 CVE-2021-3520 LZ4: memory corruption due to an integer overflow bug caused by the memmove argument

  • QUARKUS-1969 CVE-2020-36518 Jackson-databind: denial of service caused by a large depth of nested objects

8.1.2. Quarkus 2.7.5

  • QUARKUS-1970 CVE-2021-43797 Netty: control chars in header names may lead to HTTP request smuggling

  • QUARKUS-1902 CVE-2022-0981 Quarkus: privilege escalation vulnerability with RestEasy Reactive scope leakage in Quarkus

  • QUARKUS-1842 CVE-2022-21724 PostgreSQL: jdbc-postgresql: Unchecked Class Instantiation when providing Plug-in Classes

  • QUARKUS-1833 CVE-2021-22569 protobuf-java: potential DoS in the parsing procedure for binary data

  • QUARKUS-1832 CVE-2022-21363 MySQL-connector-java: Difficult to exploit vulnerability allows a high privileged attacker with network access by using multiple protocols to compromise MySQL Connectors

  • QUARKUS-1372 CVE-2021-3914 Smallrye-health-ui: persistent cross-site scripting in endpoint

  • QUARKUS-1029 CVE-2021-29429 Gradle: information disclosure through temporary directory permissions

  • QUARKUS-993 CVE-2021-29428 Gradle: local privilege escalation through system temporary directory

  • QUARKUS-992 CVE-2021-29427 Gradle: repository content filters do not work in Settings pluginManagement

  • QUARKUS-800 CVE-2020-13949 libthrift: potential DoS when processing untrusted payloads

8.2. Resolved issues

8.2.1. Quarkus 2.7.6

  • QUARKUS-2197 Use -H:PrintAnalysisCallTreeType=CSV to generate CSV call tree files

  • QUARKUS-2196 Provide contextualized response in dev and test when Jackson deserialization fails

  • QUARKUS-2195 Ease restriction on the native-sources type and container image extension

  • QUARKUS-2194 Fix NPE when setting the logger level to null

  • QUARKUS-2193 Ensure that connection issues can be handled in Reactive REST Client

  • QUARKUS-2192 Update SmallRye Config to 2.9.2

  • QUARKUS-2191 Set proper content type for DevUI template rendering

  • QUARKUS-2190 Make some additional address resolver options configurable

  • QUARKUS-2189 Update SmallRye OpenAPI to 2.1.22

  • QUARKUS-2188 Set content-length to 0 when the Reactive REST Client sends empty POST or PUT

  • QUARKUS-2187 Qute message bundles - ignore loop metadata during validation

  • QUARKUS-2185 Respect custom ConfigRoot.name in ConfigInstantiator & fix minLogLevel handling

  • QUARKUS-2184 Support large file downloads with Reactive REST Client

  • QUARKUS-2182 Support large file uploads with Reactive REST Client

  • QUARKUS-2181 Execute test plan with the deployment classloader as the TCCL

  • QUARKUS-2180 Improve usability of RESTEasy Reactive server and client multipart handling

  • QUARKUS-2179 Support Uni and CompletionStage results for multipart responses in REST Client Reactive

  • QUARKUS-2178 Panache EntityBase should flush on the right entity manager

  • QUARKUS-2176 Qute - fix validation of "cdi:" namespace expressions

  • QUARKUS-2175 Support date headers correctly in event server

  • QUARKUS-2174 Allow reflective access to Jaeger DTO classes' fields

  • QUARKUS-2173 Verify that modules are compiled in the correct order in dev mode

  • QUARKUS-2172 Register Protobuf enums in the native executable

  • QUARKUS-2169 Fix to enable non @QuarkusTest unit tests to run in parallel

  • QUARKUS-2165 Disable async Vert.x DNS resolver when for Spring Cloud Config

  • QUARKUS-2164 Resolve config folder with user.dir for YAML source

  • QUARKUS-2163 Apply some small optimizations to the generated Reactive REST Client

  • QUARKUS-2161 Add all existing project source directory in application model

  • QUARKUS-2160 Add closeBootstrappedApp mojo param to QuarkusBootstrapMojo

  • QUARKUS-2157 Improve dynamic resolution of MessageBodyWriter providers

  • QUARKUS-2155 Skip Keycloak DevService if quarkus.oidc.provider is set

  • QUARKUS-2154 Update Infinispan to 13.0.10

  • QUARKUS-2153 Fix WebSockets codestart generated package name

  • QUARKUS-2152 Maven 3.8.5 compatibility, update maven-invoker to 3.1.0

  • QUARKUS-2151 Spring API JAR version is updated to version 5.2.0.SP6

  • QUARKUS-2150 Support modules with non-empty default classifier

  • QUARKUS-2148 Enable passing of query parameters as a Map to the REST Client Reactive so advance knowledge of parameters is not needed

  • QUARKUS-2105 Upgrade to Hibernate Search 6.1.5.Final

8.2.2. Quarkus 2.7.5

  • QUARKUS-1382 JDK 17 applications deployed to OpenShift using S2I do not fail at start

  • OCPBUGSM-33066 CoreDNS now resolves the domain name for github.com in OpenShift 4.8 on OpenStack

  • QUARKUS-1544 @ServerExceptionMapper Exception type injection was allowed for use-cases where users simultaneously handle multiple exceptions

  • QUARKUS-1225 REST Client Reactive supports JSON serialization in multipart forms

  • QUARKUS-1547 Graadle and Maven multi-module projects that use the @MessageBundle annotated class now run tests successfully.

  • QUARKUS-1417 Quarkus native compilations now work in the FIPS-compliant environment

  • QUARKUS-1752 Missing dependencies for quarkus-universe-bom have been added

  • QUARKUS-1724 Deployments of a serverless application into OCP are now stable

9. Known issues

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

9.1. quarkus.openshift.arguments does not work on OpenShift with native mode enabled

Setting quarkus.openshift.arguments in native mode when the entrypoint is not set nor overridden by quarkus.openshift.command causes the following CreateContainerError error:

`runc create failed: unable to start container process: exec: \" ARG1 \ ": executable file not found in $ PATH`.
  • ARG1 can be set up using quarkus.openshift.arguments

Description

This problem occurs because the manifests of Kubernetes and OpenShift containers have two optional arguments: command and args. If these arguments are omitted, the container runs with the entry point defined in the container image. However, problems arise when only the args argument is specified.

When specifying 'args', specify command too. If not, args will be treated as the actual command, which results in Pod failure in most cases.

Workaround

To work around this problem, set the entry point with quarkus.openshift.command manually.

  • For the 'quarkus.native.builder-image' parameter not defined by the user (which is therefore set to its default value), change the entry point to 'quarkus.openshift.command=/home/quarkus/application'.

  • QUARKUS-2005

9.2. Inability of the Reactive REST client to upload files bigger than 2 Gb

Description

Quarkus REST Reactive client fails with the OutOfMemory error when uploading files bigger than 2 Gb.

9.3. Reactive REST client downloads only the first 2 Gb of file

Description

Downloading a file bigger than 2 Gb causes an issue where the Reactive REST client trims the file at 2044 MiBs. OutOfMemory log exceptions accompany the event.

9.4. Reactive REST client with NPE fails to download a multipart data that contains java.io.File

Description

The Reactive REST client fails with the NullPointerException (NPE) processing error when downloading multipart data that contains an object of the java.io.File type.

9.5. Reactive REST client duplicates paths to sub-resources

Description

When the Reactive REST client is used to access sub-resources of some HTTP resource, it duplicates the part of the address which identifies these sub-resources.

Example:
@Path("/resource")
public interface Client {

    @Path("/sub")
    SubClient getSubResource();

    interface SubClient {
        @GET
        @Path("/something")
        String getSomething();
    }

}

The call client.getSubResource().getSomething(); maps to a request to `/resource/sub/sub/something, instead of /resource/sub/something.

9.6. HTTP backlog wrong default value when using native epoll transport

Description

When quarkus.http.accept-backlog is not configured and the epoll native transport (from Netty) is enabled simultaneously, Quarkus can not handle more than x requests, where x is the cardinality of CPU cores.

This issue does not affect native executables as the native epoll transport is not integrated with the native executable.
Workaround

Using the application.properties (or from the command line), configure the quarkus.http.accept-backlog to -1:

java `-Dquarkus.http.accept-backlog=-1` -jar ....

Before you start using and deploying Red Hat build of Quarkus 2.7, review the advisories about enhancements, bug fixes, and CVE fixes for other technologies and services related to the release.

10.1. Quarkus 2.7.6

10.2. Quarkus 2.7.5

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

  • rht.subcomp: {sub-component-name}

  • rht.subcomp_t: application

Revised on 2022-07-27 07:47:21 UTC