-
Notifications
You must be signed in to change notification settings - Fork 2.7k
Migration Guide 3.4
The Vert.x HTTP configuration was migrated to the new ConfigMapping infrastructure.
The main visible change is that the configuration classes are now interfaces.
If you were consuming them in an extension to get the configuration property values (for instance by injecting io.quarkus.vertx.http.runtime.HttpConfiguration), you will have to adjust your code accordingly to use the interface methods (instead of the class fields).
Adding () at the end of each consumed field should be all that’s needed in most cases.
The Elasticsearch Dev Services now default to starting Elasticsearch 8.9, instead of 8.8 previously.
Also, Elasticsearch Dev Services will now automatically start OpenSearch instead of Elasticsearch when they detect that a Quarkus extension expects OpenSearch. Currently only the Hibernate Search extension takes advantage of this feature.
To force the use of a specific distribution (Elasticsearch vs. OpenSearch) or version, configure the container image explicitly.
Previously, annotation-based GraphQL directives got applied on any element of the GraphQL schema, regardless of whether that directive was actually declared to be applicable to that element type. This has now been fixed and the directive annotation’s on parameter is used for determining allowed placement for directives. This change might potentially break some applications that were written incorrectly but were working by accident, so if you use annotation-based GraphQL directives, we recommend verifying that their usages correspond to the directive’s declaration.
The QuarkusComponentTestExtension is now immutable.
As a result, if you register the QuarkusComponentTestExtension programmatically then the static field is initialized with with the QuarkusComponentTestExtension(Class…) simplified constructor or with the convenient QuarkusComponentTestExtension.builder().
The test instance lifecycle determines the test phase in which the CDI container is started/stopped.
If the test instance lifecycle is Lifecycle#PER_METHOD (default) then the container is started during the before each test phase and stopped during the after each test phase.
However, if the test instance lifecycle is Lifecycle#PER_CLASS then the container is started during the before all test phase and stopped during the after all test phase.
In previous versions, the the container was always started during the before all test phase and stopped during the after all test phase.