Release notes for Red Hat build of Quarkus 2.7

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

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

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

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

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.

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

The following Mutiny methods and classes have been removed:

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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

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:

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

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

{ // ... }

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.

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:

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

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:

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:

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

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.

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

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

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:

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:

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.

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.

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:

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

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.

The following CVEs have been resolved in Quarkus 2.7:

Building native images using a Red Hat build of Quarkus Native builder (JDK 17-based) such as registry.access.redhat.com/quarkus/mandrel-21-jdk17-rhel8:21.3 can produce the following error during compilation:

Fatal error:java.lang.IllegalArgumentException: java.lang.IllegalArgumentException: java.lang.IllegalArgumentException: Illegal Capacity: -1
...
Caused by: java.lang.IllegalArgumentException: Illegal Capacity: -1
at java.base/java.util.ArrayList.(ArrayList.java:160)
at com.oracle.graal.pointsto.results.StaticAnalysisResultsBuilder.makeOrApplyResults(StaticAnalysisResultsBuilder.java:97)
at com.oracle.svm.hosted.meta.UniverseBuilder.lambda$buildProfilingInformation$0(UniverseBuilder.java:354)
at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
at java.base/java.util.HashMap$EntrySpliterator.forEachRemaining(HashMap.java:1850)
at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
at java.base/java.util.stream.ForEachOps$ForEachTask.compute(ForEachOps.java:290)
at java.base/java.util.concurrent.CountedCompleter.exec CountedCompleter.java:754)
...
5 more

mvn clean package -Dnative -Dquarkus.native.additional-build-args=-H:+ParseOnce

This command overrides the Quarkus default argument, -H:-ParseOnce, because single parsing significantly increases memory usage at build time.

See https://github.com/oracle/graal/issues/3435 and https://github.com/graalvm/mandrel/issues/304#issuecomment-952070568 for more details.

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

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