-
Notifications
You must be signed in to change notification settings - Fork 3k
Migration Guide 3.22
- Jakarta REST resources with Panache
- Extensions should produce
JsonRPCProvidersBuildItemalways org.eclipse.jgitdependency is no longer managed inquarkus-bom- Stork is no longer a dependency of the REST Client
ContextResolveruse with a lambda in REST ClientQuarkusTransaction.isActive()deprecated- Deprecated
HttpAuthenticationMechanism.getCredentialTransport()method removed - Gradle
- Hibernate Reactive
|
Note
|
We highly recommend the use of Items marked below with ⚙️ ✅ are automatically handled by |
The REST Data Panache modules (quarkus-hibernate-orm-rest-data-panache, quarkus-hibernate-reactive-rest-data-panache, quarkus-mongodb-rest-data-panache and spring-data-rest) no longer work in combination with quarkus-resteasy* modules, only with quarkus-rest* modules.
Previously, the JsonRPCProvidersBuildItem was produced in most extensions only in dev mode, typically using
@BuildStep(onlyIf = IsDevelopment.class)
JsonRPCProvidersBuildItem createJsonRPCService() {
return new JsonRPCProvidersBuildItem(...);
}This is because there was only a single purpose for JsonRPCProvidersBuildItem: to register the given class for Dev UI JSON RPC.
However, The JSON RPC classes can use execution model affecting annotations (@Blocking, @NonBlocking, @RunOnVirtualThread), which Quarkus validates.
Specifically for that validation purpose, the execution model validation used to contain a gross hack that tried to guess whether the given class is a JSON RPC class, but that is being removed.
The JsonRPCProvidersBuildItem is now used as a primary source of information for which classes are Dev UI JSON RPC classes.
Therefore, the JsonRPCProvidersBuildItem should be produced always.
Quarkus will carry the gross hack for a few more releases, but it will be removed in Quarkus 3.24.
If you use the same approach as above, just replace @BuildStep(onlyIf = IsDevelopment.class) with @BuildStep.
If you use a more complex approach, it is typically possible to extract the production of JsonRPCProvidersBuildItem into a separate build step that can be executed always, while the original build step remains dev-only.
Because the JGit dependency org.eclipse.jgit:org.eclipse.jgit conflicts with the version provided in quarkus-jgit, we have decided to remove the JGit dependency from the quarkus-bom (https://github.com/quarkusio/quarkus/pull/47137). If your application uses JGit, ensure you’re using the quarkus-jgit extension, as it will support native compilation and is up-to-date with recent JGit releases.
If you are using Stork and the REST Client, you will need to add an explicit dependency to the Stork extension.
Using a lambda to define a ContextResolver in a REST Client nows throws an IllegalArgumentException.
This is done because Quarkus was unable to determine the generic type that is meant to be used (whereas previous versions fell back to using Object).
The QuarkusTransaction.isActive() method is now deprecated as its semantic wasn’t clear.
We added a getStatus() method that should be used instead.
Synchronous HttpAuthenticationMechanism.getCredentialTransport() method which was deprecated and marked for removal since Quarkus 2.8 has now been removed.
Implement Uni<HttpCredentialTransport> getCredentialTransport(RoutingContext context), for example, return Uni.createFrom().item(myHttpCredentialTransport);
The gradle tasks testNative and quarkusIntTest both no longer depend on the test task. These tasks now only execute native and integration tests, respectively.
Quarkus 3.22 makes it possible to use both Hibernate ORM (blocking) and Hibernate Reactive persistence units in the same application. This should not impact existing applications, except in the following case.
If you only used Hibernate Reactive with its corresponding datasource, but also have configured a named blocking JDBC datasource for other purposes, Hibernate ORM will now be enabled by default. Hibernate ORM’s default persistence unit requires a datasource to be configured, otherwise your application will fail to start, so you will need to either:
-
Disable Hibernate ORM by setting
quarkus.hibernate-orm.blockingtofalse, if you do not wish to use Hibernate ORM (blocking); -
Configure the datasource used by the default Hibernate ORM (blocking) persistence unit via
quarkus.hibernate-orm.datasource.