Red Hat introduces a new web-based project generator that you can use to create projects for applications based on the latest release of Red Hat build of Quarkus. The project generator provides several features that make developing new applications with Quarkus easier, such as:

You can access the project generator at code.quarkus.redhat.com. Note that Red Hat only provides support for creating Maven-based application projects with code.quarkus.redhat.com.

For more information on how to use code.quarkus.redhat.com, see Creating a Quarkus Maven project using code.quarkus.redhat.com.

Red Hat build of Quarkus 1.11 supports the use of the OpenJDK 11 Universal Base Image for building and deploying applications to Red Hat OpenShift Container Platform using the Source-to-image (S2I) tool. You can download the latest version of the image from the Red Hat Ecosystem Catalog.

Red Hat build of Quarkus 1.11 introduces a new extension for collecting runtime application metrics using the Micrometer library and Monitoring your application with Prometheus. The extension allows you to collect runtime application metrics from your applications and also from extensions that your application uses, that integrate with Micrometer (such as the Quarkus extensions for Apache Kafka, HTTP, Resteasy, and others). The Quarkus Micrometer Metrics is supported by Red Hat for use in production environments. See Collecting metrics in your Quarkus applications for more details.

In Red Hat build of Quarkus 1.11 you can define multiple data sources as persistence units when you use Hibernate ORM to manage data sources in your application. See the section about Configuring multiple JDBC data sources in Configuring data sources in your Quarkus applications for more details.

Red Hat build of Quarkus 1.11 introduces support for saving OpenAPI schemas generated for your applications with the Quarkus Smallrye OpenAPI extension. You can set the value of the quarkus-smallrye-openapi_quarkus.smallrye-openapi.store-schema-directory to the path of the directory in which the YAML and JSON files that contain the OpenAPI schemas are saved when you compile your application. For example:

quarkus-smallrye-openapi_quarkus.smallrye-openapi.store-schema-directory=/path/to/schema/directory

You can now use the Quarkus Quartz extension to schedule periodic tasks that rely on Context and Dependency Injection. See the community documentation for the Quarkus Quartz extension for details.

In Red Hat build of Quarkus 1.11, the SmallRye Reactive Messaging API used in the Quarkus Reactive Messaging Extensions for AMQP and Apache Kafka has been upgraded to version 2.7.1. See SmallRye Reactive Messaging API documentation for more details.

In Red Hat build of Quarkus 1.11, the Mutiny event-driven library used in reactive extensions for Quarkus has been upgraded to version 0.12.5.

The Reactive Routes Extensions in Red Hat build of Quarkus 1.11 supports constraint validation for Java beans.

In the Red Hat build of Quarkus 1.11 release, Jackson is set as the default ObjectMapper tool used by the Quarkus REST JSON extension. You can inject Jackson in your the REST Controller class of your application using Context and Dependency Injection to provide support for converting your REST application data to and from the JSON format. For more details about breaking changes caused by disabling the DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES feature in Jackson in Red Hat build of Quarkus 1.11, see Upgrading your applications from Red Hat build of Quarkus 1.7 to Red Hat build of Quarkus 1.11

In Red Hat build of Quarkus 1.11, you can specify the -Dquarkus.<ui-name>.always-include=true to enable user interfaces that are part of the JAR when you start the application in Production mode. The option is available for the following interfaces:

For example, when you create a JAR for a REST application that contains a SwaggerUI interface, this interface is disabled by default when you start the application. You can append the -Dquarkus.swagger-ui.always-include=true option to the start command to enable the interface when you start the application:

java -jar -Dquarkus.swagger-ui.enable=true target/<application-name>-1.0.0-SNAPSHOT-runner.jar

Note, that you must replace <application-name> with the name of your JAR.

The quarkus-rest-client extension available in Red Hat build of Quarkus 1.11 is affected by a change in the handling of WebApplicationException by MicroProfile REST Client and JAX-RS client that is introduced as part of an update that resolves the CVE-2020-25633 security issue.

As a result of the security update, RESTEasy version 4.5.9. changes the way Response is handled when a Client application returns a WebApplicationException. Before the 4.5.9 update, the Response that was sent from the remote server form the local domain contained sensitive information about the remote server (for example, cookies) that an unauthorized party could potentially gain access to.

The RESTEasy 4.5.9 update changes the way the Response contents are treated. When the local server receives the Response RESTEasy removes all the sensitive content before storing the response, but retains a way for the local server to access the original content of the Response if necessary.

This change to exception handling makes it possible to avoid the security risks associated with storing sensitive content on the local server, but still ensures that Clients using RESTEasy version 4.5.9 remain compatible with the JAX-RS specification.

For details about the change in storing Response contents in RESTEasy version 4.5.9, see the section about WebApplicationException handling in the RESTEasy 4.5.9 documentation.

In Red Hat build of Quarkus 1.11, the default base image for compiling native executables is upgraded to Mandrel 20.3. As a result, the default value of the quarkus.native.builder-image configuration property for compiling Quarkus applications to native executables changes to quay.io/quarkus/ubi-quarkus-mandrel:20.3-java11.

Red Hat build of Quarkus 1.11 includes a new version of Quarkus Kubernetes Client. If you are using the Quarkus Kubernetes Client version 4.x in a development environment and want to upgrade your existing applications to version 5.x, see the Kubernetes Client Migration Guide.

Red Hat build of Quarkus 1.11 uses includes the first release of Quarkus Dev UI. Dev UI is an experimental interface that you can use to:

You can access Dev UI when you start your application in Development mode and navigate to localhost:8080/q/dev in your web browser.

The release of Red Hat build of Quarkus 1.11 introduces several changes to the configuration properties available for the Quarkus Quartz extension.

In Red Hat build of Quarkus 1.11 the naming strategy used for Spring Boot configuration properties that contain a combination of uppercase and lowercase characters in Quarkus application is no longer set to verbatim.

Instead you can set the quarkus.arc.config-properties-default-naming-strategy property to one of the following values in the application.properties file of your project:

If you do not set the quarkus.arc.config-properties-default-naming-strategy property for your application, kebab is used as the default value.

If you are using Spring Boot configuration properties that are formatted according to the verbatim naming strategy in your application, ensure that you make one of the following changes:

Red Hat build of Quarkus 1.11 no longer supports properties for configuring the connection URLs and drivers of data sources introduced in Red Hat build of Quarkus 1.3.

You must replace the unsupported configuration properties with properties compatible with Quarkus 1.11 to ensure that your data source configuration works properly when you upgrade your application to Quarkus 1.11.

See Configuring data sources in your Quarkus applications for details on how to configure your data sources in Quarkus 1.11 applications.

In the Red Hat build of Quarkus 1.11 release, the default format for serializing application data is changed to JSON.

You can disable the default use of the JSON as content-type format for REST endpoints in your application, and use annotations to explicitly enable the use of JSON only for interfaces that you want to use it for:

In Red Hat build of Quarkus 1.11, Jackson is configured to ignore unknown properties by having the DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES disabled by default to avoid failures while attempting to deserialize JSON data objects containing properties not recognized by your application.

Set the value of the quarkus.jackson.fail-on-unknown-properties to true in the application.properties file of your application to enable the FAIL_ON_UNKNOWN_PROPERTIES feature. You must enable this feature separately for each class of your applications:

<fully-qualified-class-name>.quarkus.jackson.fail-on-unknown-properties=true

See the Quarkus REST JSON extension guide for more details about using and customizing Jackson in your Quarkus REST application.

In Quarkus 1.11, the default minimum logging level is DEBUG. This means that only log messages with a level equal to or higher than DEBUG will be processed. The log messages below the DEBUG level, such as TRACE and ALL, will not appear in your log output.

When you want to set a log level below DEBUG, you must change the minimum logging level. For example, if you configure your logger to log at TRACE level, you must set the minimum log level to TRACE.

You can set the minimum log level for a specific category in the application.properties file of your application. You must set the minimum log level before you start your application.

For example, to enable logging at the TRACE level for the io.quarkus.smallrye.jwt and io.undertow.request.security categories in your logger configuration, you can set the following properties:

quarkus.log.file.enable=true
# Send output to a trace.log file under the /tmp directory
quarkus.log.file.path=/tmp/trace.log
quarkus.log.file.level=TRACE
quarkus.log.file.format=%d{HH:mm:ss} %-5p [%c{2.}] (%t) %s%e%n
# Set 2 categories (io.quarkus.smallrye.jwt, io.undertow.request.security) to TRACE level
quarkus.log.min-level=TRACE
quarkus.log.category."io.quarkus.smallrye.jwt".level=TRACE
quarkus.log.category."io.undertow.request.security".level=TRACE

See Setting runtime configuration for more details about how you can configure logging in your Quarkus application.

In Red Hat build of Quarkus 1.11, the com.redhat.quarkus:quarkus-universe-bom no longer directly contains the goupId, artifactID and version of all extensions and dependencies. Instead, the com.redhat.quarkus:quarkus-universe-bom imports the com.redhat.quarkus:quarkus-product-bom that contains the dependency declarations for all Red Hat build of Quarkus extensions supported by Red Hat and the io.quarkus:quarkus-universe-bom that contains all the community Quarkus extensions.

This change does not impact the way that you can use the Red Hat build of Quarkus BOM in your Maven project. However, if you are using custom scripts to parse the BOM, you must update them to ensure that the parsing continues to work correctly after you upgrade your application to Red Hat build of Quarkus 1.11.

In Red Hat build of Quarkus 1.11, 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.

Example of configuring non-application endpoints under a separate namespace

For example, you can set the following properties in the application.properties file of your project to expose a hello endpoint application at the /api root path, and the metrics endpoint at the /api/q path:

quarkus.http.root-path=/api
quarkus.http.non-application-root-path=q

In this configuration, both the /api/hello and the /api/q/metrics are public. This means that any user with the permission to access the /api/hello can also send a request to the /api/q/metrics endpoint and receive a valid response.

When you want to make the health endpoint non-public, you can set the root path for non-application endpoints in the application.properties to the /q namespace:

quarkus.http.root-path=/api
quarkus.http.non-application-root-path=/q

In this configuration, the /api/hello endpoint is public, but the /q/metrics is exposed in a separate namespace for which you can configure different access permissions.

In Red Hat build of Quarkus 1.11, requests sent to the original non-application endpoint paths are automatically redirected to the new paths in the /q namespace.

You can set the following attribute in the application.properties file of your project to disable the automatic redirection of non-application endpoint paths:

quarkus.http.redirect-to-non-application-root-path=false

You can switch your applications to using the absolute endpoint root path for all endpoints by setting the value of the quarkus.http.non-application-root-path to a variable that resolves to the value of the absolute application endpoint root:

quarkus.http.non-application-root-path=${quarkus.http.root-path}

In Red Hat build of Quarkus 1.11, when you configure a Quarkus application based on Resteasy to Red Hat OpenShift Container Platform, and provide the configuration parameters for the application in a ConfigMap that is specified in the quarkus.openshift, you must also specify the quarkus.openshift.app-secret and quarkus-openshift.app-configmap properties in your application.properties file to ensure that your application recognizes and processes the ConfigMap.

The following supported extensions are added in Red Hat build of Quarkus 1.11:

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

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

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

Revised on 2021-08-20 08:37:35 UTC