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

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.