-
Notifications
You must be signed in to change notification settings - Fork 2.8k
Migration Guide 3.19
Note
|
We highly recommend the use of Items marked below with ⚙️ ✅ are automatically handled by |
We migrated all the Quarkus config properties to the new @ConfigMapping
based framework.
If you develop extensions and are injecting some configuration classes into your extensions, be aware that they are now interfaces and using methods instead of fields.
For some very commonly consumed config classes, we kept a compatibility layer for common properties but these compatibility layers will disappear in the future.
We encourage extension owners to move to the new config infrastructure based on @ConfigMapping
.
You can find a lot of examples here: https://github.com/quarkusio/quarkus/pulls?q=is%3Apr+ConfigMapping+in%3Atitle+is%3Aclosed
And don’t hesitate to ping us if you have questions or need any help.
To ease the transition, the following configuration classes have been kept around (but limited to very few properties) and are deprecated:
-
GlobalDevServicesConfig
: useDevServicesConfig
instead -
HttpConfiguration
: useVertxHttpConfig
instead -
HttpBuildTimeConfig
: useVertxHttpBuildTimeConfig
instead
In passing, we made a few adjustments to some properties that were annoying when using YAML:
-
In Vert.x HTTP,
quarkus.http.cors
is deprecated and may be replaced withquarkus.http.cors.enabled
-
In Logging JSON (the extension in Core),
quarkus.log.*.json
is deprecated and may be replaced withquarkus.log.*.json.enabled
Bean Validation integration changes its default behavior and now considers validation constraints while generating DDL.
To preserve the previous behaviour, use quarkus.hibernate-orm.validation.mode=callback
.
quarkus.hibernate-orm.validation.enabled
is deprecated. To disable the Bean Validation integration, set quarkus.hibernate-orm.validation.mode=none
instead.
Starting with Quarkus 3.19, the builder and runtime base images use UBI 9 by default, instead of UBI 8.
UBI 8 is approaching its end of support, which will raise security concerns in the future.
IMPORTANT: If you compile your native executable using an in-container (using -Dquarkus.native.container-build=true
build with a UBI 9-based builder image (which is the default starting with Quarkus 3.19), you must use a UBI 9-based runtime image.
To switch back to UBI 8:
-
For builder images, set
-Dquarkus.native.container-build=true -Dquarkus.native.builder-image=quay.io/quarkus/ubi-quarkus-mandrel-builder-image:23.1.5.0-Final-java21
-
For runtime image, in JVM mode, use
registry.access.redhat.com/ubi8/openjdk-21-runtime:1.21
as the base image of your container. -
For runtime image, in native mode, use either
registry.access.redhat.com/ubi8-minimal:8.10
if you want to use UBI minimal orquay.io/quarkus/quarkus-micro-image:2.0
for the Quarkus micro image as the base image of your container.
To update to UBI 9:
-
For builder images, it will be done automatically. However, you can specify the builder image using:
-Dquarkus.native.container-build=true -Dquarkus.native.builder-image=quay.io/quarkus/ubi9-quarkus-mandrel-builder-image:23.1.5.0-Final-java21
-
For runtime image, in JVM mode, use
registry.access.redhat.com/ubi9/openjdk-21-runtime:1.21
as the base image of your container -
For runtime image, in native mode, use either
registry.access.redhat.com/ubi9-minimal:9.5
if you want to use UBI minimal orquay.io/quarkus/ubi9-quarkus-micro-image:2.0
for the Quarkus micro image as the base image of your container.