Chapter 3. New and changed features

This section provides an overview of new features and changes introduced in Red Hat build of Quarkus 1.11.7.

3.1. The code.quarkus.redhat.com project generator

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:

  • a web-browser-based interface for selecting extension that you want to add to your project.
  • automatic generation of the project directory structure based on the build tool that you choose.
  • automatic importing and configuration of the extensions that you select to use with your applications.
  • automatic generation of starter code for your application.

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.

3.2. Use of OpenJDK 11 Universal Base Image as the new default base image for Source-to-image builds

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.

3.3. New Micrometer Metrics extension for monitoring your Quarkus applications with Prometheus

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.

3.4. Support for multiple Hibernate ORM persistence units

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.

3.5. Support for saving generated OpenAPI schemas

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:

application.properties

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

3.6. ArC Context and Dependency Injection support in the Quarkus Quartz extension

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.

3.7. SmallRye Reactive Messaging upgrade to version 2.7.1

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.

3.8. Mutiny reactive API upgrade to version 0.12.5

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.

3.9. Support for Bean Validation in Reactive Routes

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

3.10. Change to Jackson as the default JSON serialization and deserialization tool for Quarkus REST applications

Warning

This change might break the REST endpoints in your application when you upgrade your application from Red Hat build of Quarkus 1.7 to Red Hat build of Quarkus 1.11. Update your application code to ensure that object mapping works correctly after you upgrade your applications.

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

3.11. New option for enabling non-application user interfaces when starting your application in Production mode

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:

  • Swagger UI
  • OpenAPI
  • SmallRye Health UI
  • GraphQL UI

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.

3.12. Quarkus REST Client security update to resolve CVE-2020-25633

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.

3.13. Upgrade of the default Mandrel base image for compiling native executables to version 20.3

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.

3.14. Quarkus Kubernetes Client upgraded to version 5.x

Important

Red Hat does not provide support for using the Quarkus Kubernetes Client in production environments.

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.

3.15. Quarkus Dev UI

Important

Red Hat does not provide support for using the Quarkus Dev UI in production environments.

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:

  • view a list of extension that you are currently using in your application,
  • see the status of the extensions in your application
  • access the documentation for the extensions that you are using in your application.

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