Red Hat a publié Quarkus 2.8.0 qui offre une intégration avec la couche RESTEasy Reactive REST et GraalVM 22.0 par défaut. Une API de transaction programmatique à grain fin offre plus de contrôle sur les transactions.
Quarkus 1.11 a introduit l'intégration avec RESTEasy Reactive, une implémentation réactive de JAX-RS et implémentée avec Vert.x. Avec cette version, RESTEasy Reactive est désormais l'implémentation par défaut et prend en charge les appels bloquants et réactifs, sélectionnés automatiquement en fonction du type de retour du endpoint. Par exemple, renvoyer un Student rend le endpoint bloquant, tandis que renvoyer un Uni<Student> rend le endpoint réactif. Jusqu'à récemment, la couche REST par défaut était RESTEasy Classic, et elle est toujours disponible après ajout manuel aux dépendances du projet.
Toutes les dépendances quarkus-resteasy* d'un serveur REST doivent être remplacées par les dépendances quarkus-resteasy-reactive*, à l'exception de la dépendance quarkus-resteasy-mutiny puisque la fonctionnalité est intégrée dans RESTEasy Reactive. Après cela, les différentes annotations, telles que org.jboss.resteasy.annotations.jaxrs.QueryParam, doivent être remplacées par les annotations org.jboss.resteasy.reactive* telles que org.jboss.resteasy.reactive.RestQuery.
De même, les implémentations de REST client doivent remplacer les dépendances quarkus-rest-client* par les nouvelles dépendances quarkus-rest-client-reactive*.
Le guide de migration et le guide de référence de RESTEasy Reactive offre des conseils supplémentaires sur la migration.
L'API QuarkusTransaction propose désormais une API programmatique pour contrôler les transactions en appelant explicitement les méthodes begin() et commit() :
QuarkusTransaction.begin();
// implementation
QuarkusTransaction.commit();
Cette transaction est liée à la portée request de CDI et est automatiquement annulée (roll back) chaque fois qu'une exception détruit la portée request. Alternativement, il est possible de démarrer la transaction avec un délai d'attente et de faire un roll back chaque fois que le délai d'attente se produit :
QuarkusTransaction.begin(QuarkusTransaction.beginOptions()
.timeout(42));
// implementation
QuarkusTransaction.rollback();
Les transactions définies via une Lambda offrent une autre alternative en exécutant un Runnable dans une transaction :
QuarkusTransaction.run(() -> {
// implementation
});
Alternativement, une solution Callable peut être utilisée qui prend en charge la gestion des exceptions et la sémantique d'énumération DISALLOW_EXISTING, JOIN_EXISTING, SUSPEND_EXISTING, REQUIRE_NEW (par défaut) :
int answer = QuarkusTransaction.call(QuarkusTransaction.runOptions()
.timeout(21)
.exceptionHandler((throwable) -> {
if (throwable instanceof RuntimeException) {
return RunOptions.ExceptionResult.COMMIT;
}
return RunOptions.ExceptionResult.ROLLBACK;
})
.semantic(RunOptions.Semantic.REQUIRE_NEW), () -> {
// implementation
return 42;
});
GraalVM 22.0, déjà pris en charge avec la sortie de Quarkus 2.7, est désormais utilisé par défaut, offrant une journalisation améliorée lors de la création d'une image native.
Quarkus prend désormais en charge Proof Of Key for Code Exchange (PKCE) pour OpenID Connect (OIDC), une couche d'identité au-dessus du protocole OAuth 2.0. PKCE est une extension d'OAuth 2.0 pour atténuer les menaces de sécurité lorsqu'un client public demande un jeton d'accès.
Les responsables ont décidé de supprimer AssertJ du Bill of Materials (BOM) car les nouvelles versions brisaient souvent la compatibilité binaire. Les projets doivent désormais déclarer explicitement AssertJ 3.22.0, actuellement la dernière version.
Elasticsearch Dev Services démarre automatiquement un conteneur Elasticsearch lors de l'exécution des tests en mode dev et test lorsqu'une extension Elasticsearch est utilisée, sauf si explicitement désactivé avec, par exemple, quarkus.devservices.enabled défini sur false.
Quarkus propose un guide de migration pour faciliter la transition vers la version 2.8.0.