Migration Guide 3.19

Table of Contents

• Config changes
  • Compatibility layers
  • Other changes ⚙️ ✅
• Testing
  • Mockito inline strategy

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

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.