Dans le précédent post sur le buildItem AdditionalBeanBuildItem, nous avons vu comment référencer un bean au gestionnaire de dépendance ARC.
Cela est très pratique, mais dans certains cas, nous voulons pouvoir que le gestionnaire injecte une instance spécifique d’un bean déjà configuré. L’AdditionalBeanBuildItem ne prenant qu’une classe de bean
en paramètre, il ne peut pas être utilisé pour cela. C’est ici qu’intervient le SyntheticBeanBuildItem
J’ai récemment dû implémenter une bibliothèque permettant de valider un JWT dans le cadre d’une authentification OIDC avec Keycloak. Afin de tester que ma bibliothèque fonctionnait correctement au niveau de la partie validation du token, j’ai dû générer un token signé. Ma bibliothèque utilise la bibliothèque de Keycloak pour la vérification. Celle de keycloak fait appel au well-known pour récupérer les informations sur la clé RSA qui à servi à signer les tokens. Voyons un peu comment faire tout cela sans avoir à démarrer et à configurer un Keycloak entier juste pour des tests.
On continue avec les différentes manières d’indexer des Beans via une extension Quarkus
avec l’AdditionalApplicationArchiveMarkerBuildItem. Ce build item permet en quelques sorts de faire en une seule
étape ce que fait la combinaison CombinedIndexBuildItem et AdditionalBeanBuildItem.
Après les ApplicationIndexBuildItem et CombinedIndexBuildItem continuons notre tour des builds items Quarkus
avec l’AdditionalBeanBuildItem. Ce build item fait partie des items permettant le paramétrage de la bibliothèque Arc
en charge de la gestion de l’injection de dépendance dans Quarkus.
Quarkus dispose d’un système d’extension très puissant basé sur le concept de BuildItem. Chaque BuildItem permettant
de configurer une extension de manière bien particulière. Cependant, la documentation de ces BuildItem est très incomplète.
Parmi les centaines de BuildItems existant, je vous propose d’en étudier deux dans ce post.
Focus sur les ApplicationIndexBuildItem et CombinedIndexBuildItem
La Developer Experience (DX) est une discipline récente, mais qui mérite que l’on s’y attarde.
Paradoxalement, le développeur est souvent le parent pauvre du mouvement Agile alors que la cible première
était bien ce dernier. Là où la User Experience (UX) se propose d’améliorer l’expérience utilisateur en la rendant
la plus simple et cohérente possible, la DX remplace l’utilisateur final par le développeur. La DX fait partie de la
philosophie DevOps mais centrée sur le Dev au lieu de l’Ops. Elle vient en complément du “CraftmanShip” où le développeur
agit sur la qualité du code. Avec la DX, c’est l’entreprise qui agit pour améliorer l’expérience utilisateur de ses développeurs.
