Migration Guide 3.22

Table of Contents

• Jakarta REST resources with Panache
• Extensions should produce JsonRPCProvidersBuildItem always
• org.eclipse.jgit dependency is no longer managed in quarkus-bom
• ContextResolver use with a lambda in REST Client
• QuarkusTransaction.isActive() now checks if the transaction is in the active state
• @Singleton is no longer a bean defining annotation in strict mode

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.

Jakarta REST resources with Panache

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.

Extensions should produce JsonRPCProvidersBuildItem always

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.

org.eclipse.jgit dependency is no longer managed in quarkus-bom

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.

ContextResolver use with a lambda in REST Client

Using a lambda to define a ContextResolver in a REST Client nows throws an IllegalArgumentException. This is done because the Quarkus unable to detetmine the generic type that is meant to be used (whereas previous versions fell back to using Object).

QuarkusTransaction.isActive() now checks if the transaction is in the active state

The QuarkusTransaction.isActive() method now checks if the transaction is in the Status.ACTIVE_STATUS state, changing the original behavior that returned true if the status of the current transaction was everything but not in a transaction.

We have also added a getStatus() method for fine-grained use cases.

@Singleton is no longer a bean defining annotation in strict mode

In the CDI strict compatibility mode (quarkus.arc.strict-compatibility=true), the @Singleton annotation is no longer treated as a bean defining annotation. This fixes a bug in CDI specification compatibility, because CDI specifies that pseudo-scope annotations are not bean defining annotations, except @Dependent.

If you don’t use the strict compatibility mode, this doesn’t affect you. In the default mode, @Singleton is still treated as a bean defining annotation, just because it makes sense.