Release Notes for Red Hat build of Quarkus 1.3
These release notes list new features, features in technology preview, known issues, and issues fixed in Red Hat build of Quarkus 1.3.
Chapter 1. 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, Apache Kafka, RESTEasy (JAX-RS), Hibernate ORM (JPA), Spring, Infinispan, and Apache Camel.
The Quarkus dependency injection solution is based on CDI (contexts and dependency injection) and includes an extension framework to expand functionality and to configure, boot, and integrate a framework into your application.
Quarkus provides a container-first approach to building Java applications. This approach makes it much easier to build microservices-based applications written in Java as well as enabling those applications to invoke functions running on serverless computing frameworks. For this reason, Quarkus applications have small memory footprints and fast start-up times.
Chapter 2. Red Hat build of Quarkus supported platforms, configurations, extensions, and dependencies
This section lists supported environments, configurations, extensions, and dependencies in Red Hat build of Quarkus.
2.1. Tested and verified environments
Red Hat build of Quarkus is supported on the following platforms:
- Red Hat Enterprise Linux 8
- Red Hat OpenShift Container Platform 3.11 on x86_64
- Red Hat OpenShift Container Platform 4.3 on x86_64
- Red Hat OpenShift Container Platform 4.3 on IBM Z (supported with Quarkus 1.3.4)
Only the database client is tested and verified, not the server.
2.2. Supported configurations
- For a list of supported configurations, see the Red Hat build of Quarkus Supported Configurations page (login required).
- For a list of supported Maven artifacts see the Red Hat build of Quarkus Component Details page (login required).
2.3. Supported extensions and dependencies
Red Hat provides production support for the following Red Hat build of Quarkus extensions and dependencies:
2.4. Development support
Red Hat provides development support for the following Red Hat build of Quarkus features, plug-ins, extensions, and dependencies:
- Live development mode
Quarkus Maven plug-in (
Maven Surefire plug-in (
Extensions and dependencies
Chapter 3. Deprecated components and features
The components and features listed in this section are deprecated with Red Hat build of Quarkus 1.3. 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.
- The use of ReactiveX APIs
Chapter 4. Technology preview
This section lists features and extensions that are in Technology Preview in Red Hat build of Quarkus 1.3.
These features are for Technology Preview only. 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 on Red Hat Technology Preview features, see Technology Preview Features Scope.
- Native compilation using GraalVM
- Remote development
Extensions and dependencies
Chapter 5. Known issues
This section lists known issues with Red Hat build of Quarkus 1.3.
If you add the
smallrye-reactive-messagingextension, a warning message about ReactiveX appears when you close Quarkus even if you are not using Reactive APIs in your code. For more information, see Red Hat article 4954651.
quarkus-container-image-s2extension, which is typically used indirectly through the
quarkus-openshiftextension, treats the Red Hat OpenJ9 images recommended for s390x architecture as if they do not include the
run-java.shscript. This affects the generated
If the image uses the
run-java.shscript, the container definition only includes several environment variables. It does not include a command that should be executed in the container. Instead, the default S2I
runscript is used which executes the
If the image does not use the
run-java.shscript, the container definition includes the
javacommand that should be executed in the container.
One difference between these scenarios is that the
run-java.shscript changes the current working directory to the directory where the application JAR file is located, typically
/deployments. This is important when mounting a ConfigMap with the
application.propertiesconfiguration file into the container filesystem. With the
run-java.shscript, the ConfigMap typically must be mounted into the
/deployments/configdirectory, while with the other images, the ConfigMap must be mounted into the default working directory defined by the image.Note
This issue does not affect all applications that use the Red Hat OpenJ9 images recommended for s390x architecture.
quarkus-container-image-s2iextension has a list of known images that contain the
run-java.shscript. All other images are treated as if they do not contain the
run-java.shscript. This issue will be fixed in a future release.
If your application is affected by the current working directory issue, you can define the current working directory of the container in the pod definition. This overrides the default working directory defined in the image. If you use the
quarkus-openshiftextension to generate the
openshift.ymlfile, use the following configuration property:
If your application is affected by the current working directory issue specifically when mounting a ConfigMap with the
application.propertiesconfiguration file, another option is to mount the ConfigMap into a specific directory. If you use the
quarkus-openshiftextension, use following configuration property, assuming that the default working directory defined by the image is
Chapter 6. Fixed issues in Quarkus 1.3.4
Quarkus 1.3.4 provides increased stability and fixed issues listed in this section.
6.1. Major changes
Performance improvements on multi-core systems:
Several scalability issues were identified and fixed in JBoss Threads. JBoss Threads has been upgraded to version 3.1.1.Final which significantly improves scalability on multi-core systems.
Performance improvements related to suboptimal bean scopes:
Upgraded to Quarkus HTTP 3.0.7.Final which fixes several issues related to websockets and HTTP/2:
- The environment variables from secrets were generated in such a way that Quarkus was incompatible with OpenShift 3.11.
- The OpenID Connect extension was not removing cookies if the cookie path was set. This issue was fixed here.
Several fixes were made to clustering support for the Quartz extension:
6.2. Minor changes
- The PostgreSQL JDBC driver was upgraded to 42.2.12 because several regressions were spotted in 42.2.11.
- The health probes were missing from the descriptor generated by the container image extension if a container image name was specified.
- In certain cases, when a configuration error occurred at bootstrap, the exception was swallowed which made issues difficult to diagnose. The error is now properly logged in all cases.
- The Spring Data compatibility extension now supports primitive types.
- Updated SnakeYAML to 1.26 to fix CVE (security issue).
6.3. Fixed issues in Quarkus 1.3.4 SP1
The Quarkus 1.3.4 SP1 release contains the following bug fixes.
Revised on 2020-12-08 19:29:33 UTC