Skip to content

Migration Guide 3.19

Guillaume Smet edited this page Feb 14, 2025 · 8 revisions
Note

We highly recommend the use of quarkus update to update to a new version of Quarkus.

Items marked below with ⚙️ ✅ are automatically handled by quarkus update.

Config changes

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.

Compatibility layers

To ease the transition, the following configuration classes have been kept around (but limited to very few properties) and are deprecated:

  • GlobalDevServicesConfig: use DevServicesConfig instead

  • HttpConfiguration: use VertxHttpConfig instead

  • HttpBuildTimeConfig: use VertxHttpBuildTimeConfig instead

Other changes ⚙️ ✅

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 with quarkus.http.cors.enabled

  • In Logging JSON (the extension in Core), quarkus.log.*.json is deprecated and may be replaced with quarkus.log.*.json.enabled

Hibernate ORM

Bean Validation integration

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.

Testing

Mockito inline strategy

When the quarkus-junit5-mockito dependency, Mockito is now configured to used the (default) inline stategy as opposed to the subclass strategy that previously being employed.

UBI 9

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 or quay.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 or quay.io/quarkus/ubi9-quarkus-micro-image:2.0 for the Quarkus micro image as the base image of your container.

Current version

Migration Guide 3.18

Next version in main

Migration Guide 3.19

Clone this wiki locally