Lors du d\u00e9veloppement d’une application, il est tr\u00e8s fr\u00e9quent d’avoir plusieurs impl\u00e9mentations d’un service, et de devoir s\u00e9lectionner l’une o\u00f9 l’autre en fonction de l\u2019environnement sur lequel elle est d\u00e9ploy\u00e9e.<\/p>\n
Un exemple classique : un service qui appelle une API d’un partenaire externe qu’on veut appeler uniquement en production, et donc mocker sur les environnements de d\u00e9veloppement et de test \/ UAT \/ staging.<\/p>\n
Quarkus essaye de d\u00e9porter au build time, via son plugin Maven ou Gradle, le plus de choses possibles. Entre autre, il d\u00e9couvre les beans CDI au build time, et ne va instancier que ceux n\u00e9cessaire au runtime.<\/p>\n
Pour pouvoir s\u00e9lectionner un bean, on a la possibilit\u00e9 d’utiliser l’annotation @IfBuildProfile<\/code>code>@IfBuildProfile<\/code<\/a><\/a>, l’annotation @IfBuildProperty<\/code>code>@IfBuildProperty<\/code<\/a><\/a>, ou les alternatives CDI<\/a>. Mais ces solutions vont s\u00e9lectionner le bean au build time! Cel\u00e0 permet d’avoir un bean diff\u00e9rent pour les tests unitaires ou le dev mode mais pas une fois que l’application a \u00e9t\u00e9 construite. Pour utiliser ce m\u00e9canisme pour s\u00e9lectionner un bean diff\u00e9rent sur un environement UAT\/staging et sur la prod, il faudrait builder plusieurs packages de l’application.<\/p>\n S\u00e9lectionner un bean au runtime reste possible en utilisation une Voici comment faire.<\/p>\n Etape 1<\/strong> : ajouter une propri\u00e9t\u00e9 dans votre Etape 2<\/strong> : annoter vos deux impl\u00e9mentations avec un qualifier CDI, ici on utilisera @Named<\/code>code>@Named<\/code<\/a> mais Quarkus propose aussi @Identifier<\/code>code>@Identifier<\/code<\/a>.<\/p>\n Etape 3<\/strong> : dans la classe utilisant votre service, s\u00e9lectionner le bean au d\u00e9marrage de l’application en vous basant sur la configuration de l’application.<\/p>\n MISE A JOUR<\/strong> : Martin Kouba (merci \u00e0 lui) a propos\u00e9 une impl\u00e9mentation plus courte et clair, via injection dans le constructeur (ce que, \u00e0 ma grand honte, je ne suis pas du tout familier). Je vous met donc ci-dessous une \u00e9tape 3 avec un code simplifi\u00e9 :<\/p>\n Attention<\/strong> : les d\u00e9finitions (metadata) deux beans Conclusion : m\u00eame si s\u00e9lectionner un bean au runtime va \u00e0 l’encontre de la philosophie de Quarkus, c’est bien souvent une n\u00e9cessit\u00e9 et cela reste possible via quelques lignes de code. Comme c’est quelque chose de classique, je vais \u00e9voquer le point avec la communaut\u00e9 Quarkus pour qu’on trouve quelque chose de plus pratique, stay tuned ;)<\/p>\n MISE A JOUR<\/strong> : J’ai depuis \u00e9voqu\u00e9 le point avec la communaut\u00e9 Quarkus et une solution plus pratique que l’utilisation de On peut donc remplacer les \u00e9tapes 2 et 3 pr\u00e9c\u00e9dentes par celles-ci :<\/p>\n Etape 2<\/strong> : annoter vos deux impl\u00e9mentations avec @LookupIfProperty<\/code>code>@LookupIfProperty<\/code<\/a>.<\/p>\n Etape 3<\/strong> : dans la classe utilisant votre service, le bean doit \u00eatre obtenu au d\u00e9marrage via la m\u00e9thode <\/p>","protected":false},"excerpt":{"rendered":" Lors du d\u00e9veloppement d’une application, il est tr\u00e8s fr\u00e9quent d’avoir plusieurs impl\u00e9mentations d’un service, et de devoir s\u00e9lectionner l’une o\u00f9 l’autre en fonction de l\u2019environnement sur lequel elle est d\u00e9ploy\u00e9e. Un exemple classique : un service qui appelle une API d’un partenaire externe qu’on veut appeler uniquement en production, et donc mocker sur les environnements de d\u00e9veloppement et de test \/ UAT \/ staging. Quarkus essaye de d\u00e9porter au build time, via son plugin Maven ou Gradle, le plus de…Instance<\/code> CDI, cela n\u00e9cessite quelques lignes de code.<\/p>\napplication.properties<\/code><\/p>\nservice.implementation-name=mock\n<\/pre>\n
@ApplicationScoped\n@Named(\"mock\")\npublic class MockService implements RemoteService {\n \/\/ ....\n}\n<\/pre>\n@ApplicationScoped\n@Named(\"real\")\npublic class RealService implements RemoteService {\n \/\/ ....\n}\n<\/pre>\n@Path(\"\/api\")\npublic class MyEndpoint {\n @ConfigProperty(name=\"service.implementation-name\") String implementationName;\n @Inject InstanceremoteServiceInstance;\n\n private RemoteService remoteService;\n\n @PostConstruct\n void init() {\n remoteService = remoteServiceInstance\n .select(NamedLiteral.of(implementationName)).get();\n }\n\n \/\/ ...\n}\n<\/pre>\n@Path(\"\/api\")\npublic class MyEndpoint { \n private final RemoteService remoteService;\n\n MyEndpoint(@ConfigProperty(name=\"service.implementation-name\") String implName, \n Instance remoteServiceInstance) {\n remoteService = remoteServiceInstance.select(NamedLiteral.of(implName)).get();\n }\n\n \/\/ ...\n}\n<\/pre>\nMockService<\/code> et RemoteService<\/code> seront cr\u00e9\u00e9es et resterons en m\u00e9moire tout au long de la vie de votre application, m\u00eame si uniquement l’un des deux sera utilis\u00e9. Elles ne seront pas supprim\u00e9es automatiquement par Arc, l’impl\u00e9mentation CDI de Quarkus, via son m\u00e9canisme de suppression de bean inutilis\u00e9<\/a>. Les beans quand \u00e0 eux, s’ils utilisent un scope normal, seront cr\u00e9\u00e9 de mani\u00e8re lazy<\/a>.<\/p>\ninstance.select()<\/code> a \u00e9t\u00e9 impl\u00e9ment\u00e9e gr\u00e2ce aux annotations @LookupIfProperty<\/code>code>@LookupIfProperty<\/code<\/a> et @LookupUnlessProperty<\/code>code>@LookupUnlessProperty<\/code<\/a> qui permettent d’ajouter, pour chaque bean, une condition pour leur s\u00e9lection en fonction d’une propri\u00e9t\u00e9 de configuration.<\/p>\n@ApplicationScoped\n@LookupIfProperty(name = \"service.implementation-name\", stringValue = \"mock\")\npublic class MockService implements RemoteService {\n \/\/ ....\n}\n<\/pre>\n@ApplicationScoped\n@LookupIfProperty(name = \"service.implementation-name\", stringValue = \"real\")\npublic class RealService implements RemoteService {\n \/\/ ....\n}\n<\/pre>\nget()<\/code> de l’instance. La pr\u00e9sence de l’annotation @LookupIfProperty<\/code>code>@LookupIfProperty<\/code<\/a> sur les deux impl\u00e9mentations fera que seul le bean de type MockService<\/code> sera cr\u00e9\u00e9 car la valeur de la propri\u00e9t\u00e9 service.implementation-name<\/code> utilis\u00e9 dans son instance de @LookupIfProperty<\/code>code>@LookupIfProperty<\/code<\/a> est mock<\/code>.<\/p>\n@Path(\"\/api\")\npublic class MyEndpoint {\n @Inject InstanceremoteServiceInstance;\n\n private RemoteService remoteService;\n\n @PostConstruct\n void init() {\n remoteService = remoteServiceInstance.get();\n }\n\n \/\/ ...\n}\n<\/pre>\n