When developing an application, it is very common to have several implementations of a servicen and to have to select one or the other depending on the environment on which it is deployed.<\/p>\n
A classic example: a service that calls an API of an external partner that we want to call only in production, and therefore mock on the development and test \/ UAT \/ staging environments.<\/p>\n
Quarkus tries to move to build time, via its Maven or Gradle plugin, the most possible things. Among other things, it discovers CDI beans at build time, and will instantiate only those necessary.<\/p>\n
To be able to select a bean, we have the possibility to use the @IfBuildProfile<\/code>code>@IfBuildProfile<\/code<\/a><\/a> annotation, the @IfBuildProperty<\/code>code>@IfBuildProperty<\/code<\/a><\/a>, or CDI alternatives<\/a>. But these solutions will select the bean at build time! This allows to have a different bean for unit tests or dev mode but not once the application has been built. To use this mechanism to select a different bean on a UAT\/staging environment and on the production, you would have to build several packages of the application.<\/p>\n Selecting a bean at runtime is still possible using a CDI Here is how to do it.<\/p>\n Step 1<\/strong>: add a property in your Step 2<\/strong>: annotate your two implementations with a CDI qualifier, here we will use @Named<\/code>code>@Named<\/code<\/a> but Quarkus also offers @Identifier<\/code>code>@Identifier<\/code<\/a>.<\/p>\n Step 3<\/strong>: In the class using your service, select the bean at application startup based on the application configuration.<\/p>\n UPDATE<\/strong> : Martin Kouba (thanks to him) proposed a shorter and clearer implementation, via constructor injection (which, to my great shame, I am not familiar with). So I put below a step 3 with a simplified code:<\/p>\n Caution<\/strong> : the definitions (metadata) of the two beans Conclusion: even if selecting a bean at runtime goes against the philosophy of Quarkus, it is very often a necessity and it is possible via a few lines of code. As it is something classic, I will raise the point with the Quarkus community so that we find something more practical, stay tuned ;)<\/p>\n UPDATE<\/strong> : I have since raised the point with the Quarkus community and a more practical solution than using So we can replace the previous steps 2 and 3 with these:<\/p>\n Step 2<\/strong>: annotate both your implementations with @LookupIfProperty<\/code>code>@LookupIfProperty<\/code<\/a>.<\/p>\n Step 3<\/strong>: In the class using your service, the bean must be obtained at startup via the <\/p>","protected":false},"excerpt":{"rendered":" When developing an application, it is very common to have several implementations of a servicen and to have to select one or the other depending on the environment on which it is deployed. A classic example: a service that calls an API of an external partner that we want to call only in production, and therefore mock on the development and test \/ UAT \/ staging environments. Quarkus tries to move to build time, via its Maven or Gradle plugin,…Instance<\/code>, it requires a few lines of 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 Instance remoteServiceInstance;\n\n private final 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 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> and RemoteService<\/code> will be created and will remain in memory for the life of your application, even if only one of the two will be used. They will not be deleted automatically by Arc, the CDI implementation of Quarkus, via its unused bean deletion<\/a> mechanism. The beans, on the other hand, if they use a normal scope, will be created in a lazy<\/a> manner.<\/p>\ninstance.select()<\/code> has been implemented thanks to the @LookupIfProperty<\/code>code>@LookupIfProperty<\/code<\/a> and @LookupUnlessProperty<\/code>code>@LookupUnlessProperty<\/code<\/a> annotations that allow to add, for each bean, a condition for their selection based on a configuration property.<\/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> method of the instance. The presence of the @LookupIfProperty<\/code>code>@LookupIfProperty<\/code<\/a> annotation on both implementations will cause only the bean of type MockService<\/code> to be created because the value of the service.implementation-name<\/code> property used in its @LookupIfProperty<\/code>code>@LookupIfProperty<\/code<\/a> instance is 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