Quarkus依賴注入:用注解選擇注入Bean
作者:程序員欣宸
本篇學習一個與創建Bean有關的重要知識點:一個接口如果有多個實現類時,Bean實例應該如何選擇其中的一個呢?可以用注解來設定Bean的選擇邏輯。
本篇概覽
- 本文是《quarkus依賴注入》系列的第三篇,前文咱們掌握了創建bean的幾種方式,本篇趁熱打鐵,學習一個與創建bean有關的重要知識點:一個接口如果有多個實現類時,bean實例應該如何選擇其中的一個呢?可以用注解來設定bean的選擇邏輯。
- 如果您熟悉spring,此刻應該會想到ConditionalXXX注解,下面的代碼來自spring官方,注解ConditionalOnProperty的作用是根據配置信息來控制bean是否實例化,本篇咱們要掌握的是quarkus框架下的類似控制邏輯。
@Service
@ConditionalOnProperty(
value="logging.enabled",
havingValue = "true",
matchIfMissing = true)
class LoggingService {
// ...
}
- 本篇主要是通過實例學習以下五個注解的用法。
- LookupIfProperty,配置項的值符合要求才能使用bean。
- LookupUnlessProperty,配置項的值不符合要求才能使用bean。
- IfBuildProfile,如果是指定的profile才能使用bean。
- UnlessBuildProfile,如果不是指定的profile才能使用bean。
- IfBuildProperty,如果構建屬性匹配才能使用bean。
源碼下載
- 本篇實戰的完整源碼可在GitHub下載到,地址和鏈接信息如下表所示(https://github.com/zq2599/blog_demos)。
- 這個git項目中有多個文件夾,本次實戰的源碼在quarkus-tutorials文件夾下,如下圖紅框。
- quarkus-tutorials是個父工程,里面有多個module,本篇實戰的module是basic-di,如下圖紅框。
LookupIfProperty,配置項的值符合要求才能使用bean
- 注解LookupIfProperty的作用是檢查指定配置項,如果存在且符合要求,才能通過代碼獲取到此bean。
- 有個關鍵點請注意:下圖是官方定義,可見LookupIfProperty并沒有決定是否實例化beam,它決定的是能否通過代碼取到bean,這個代碼就是Instance<T>來注入,并且用Instance.get方法來獲取。
- 定義一個接口TryLookupIfProperty.java。
public interface TryLookupIfProperty {
String hello();
}
- 以及兩個實現類,第一個是TryLookupIfPropertyAlpha.java。
public class TryLookupIfPropertyAlpha implements TryLookupIfProperty {
@Override
public String hello() {
return "from " + this.getClass().getSimpleName();
}
}
- 第二個TryLookupIfPropertyBeta.java。
public class TryLookupIfPropertyBeta implements TryLookupIfProperty {
@Override
public String hello() {
return "from " + this.getClass().getSimpleName();
}
}
- 然后就是注解LookupIfProperty的用法了,如下所示,SelectBeanConfiguration是個配置類,里面有兩個方法用來生產bean,都用注解LookupIfProperty修飾,如果配置項service.alpha.enabled的值等于true,就會執行tryLookupIfPropertyAlpah方法,如果配置項service.beta.enabled的值等于true,就會執行tryLookupIfPropertyBeta方法。
package com.bolingcavalry.config;
import com.bolingcavalry.service.TryLookupIfProperty;
import com.bolingcavalry.service.impl.TryLookupIfPropertyAlpha;
import com.bolingcavalry.service.impl.TryLookupIfPropertyBeta;
import io.quarkus.arc.lookup.LookupIfProperty;
import javax.enterprise.context.ApplicationScoped;
public class SelectBeanConfiguration {
@LookupIfProperty(name = "service.alpha.enabled", stringValue = "true")
@ApplicationScoped
public TryLookupIfProperty tryLookupIfPropertyAlpha() {
return new TryLookupIfPropertyAlpha();
}
@LookupIfProperty(name = "service.beta.enabled", stringValue = "true")
@ApplicationScoped
public TryLookupIfProperty tryLookupIfPropertyBeta() {
return new TryLookupIfPropertyBeta();
}
}
- 然后來驗證注解LookupIfProperty是否生效,下面是單元測試代碼,有兩處需要注意的地方,稍后會提到。
package com.bolingcavalry;
import com.bolingcavalry.service.TryLookupIfProperty;
import com.bolingcavalry.service.impl.TryLookupIfPropertyAlpha;
import io.quarkus.test.junit.QuarkusTest;
import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.BeforeAll;
import org.junit.jupiter.api.Test;
import javax.enterprise.inject.Instance;
import javax.inject.Inject;
@QuarkusTest
public class BeanInstanceSwitchTest {
@BeforeAll
public static void setUp() {
System.setProperty("service.alpha.enabled", "true");
}
// 注意,前面的LookupIfProperty不能決定注入bean是否實力話,只能決定Instance.get是否能取到,
//所以此處要注入的是Instance,而不是TryLookupIfProperty本身
@Inject
Instance<TryLookupIfProperty> service;
@Test
public void testTryLookupIfProperty() {
Assertions.assertEquals("from " + tryLookupIfPropertyAlpha.class.getSimpleName(),
service.get().hello());
}
}
- 上述代碼有以下兩點要注意。
- 注意TryLookupIfProperty的注入方式,對這種運行時才能確定具體實現類的bean,要用Instance的方式注入,使用時要用Instance.get方法取得bean。
- 單元測試的BeforeAll注解用于指定測試前要做的事情,這里用System.setProperty設置配置項service.alpha.enabled,所以,理論上SelectBeanConfiguration.tryLookupIfPropertyAlpha方法應該會執行,也就是說注入的TryLookupIfProperty應該是TryLookupIfPropertyAlpha實例,所以testTryLookupIfProperty中用assertEquals斷言預測:TryLookupIfProperty.hello的值來自TryLookupIfPropertyAlpha。
- 執行單元測試,如下圖,符合預期。
- 修改BeanInstanceSwitchTest.setUp,將service.alpha.enabled改成service.alpha.enabled,如此理論上SelectBeanConfiguration.tryLookupIfPropertyBeta方法應該會執行,實例化的應該就是TryLookupIfPropertyBeta,那么本次單元測試就不能通過了。
- 如下圖,果然,注入的實例變成了TryLookupIfPropertyBeta,但是預期的還是之前的TryLookupIfPropertyAlpha,于是測試失敗。
LookupUnlessProperty,配置項的值不符合要求才能使用bean
- LookupIfProperty的意思是配置項的值符合要求才會創建bean,而LookupUnlessProperty恰好相反,意思是配置項的值不符合要求才能使用bean。
- 為了驗證LookupUnlessProperty的效果,修改SelectBeanConfiguration.java,只修改tryLookupIfPropertyBeta方法的注解,由從之前的LookupIfProperty改為LookupUnlessProperty,屬性也改為service.alpha.enabled,現在的邏輯是:如果屬性service.alpha.enabled的值是true,就執行tryLookupIfPropertyAlpha,如果屬性service.alpha.enabled的值不是true,就執行tryLookupIfPropertyBeta。
public class SelectBeanConfiguration {
@LookupIfProperty(name = "service.alpha.enabled", stringValue = "true")
@ApplicationScoped
public TryLookupIfProperty tryLookupIfPropertyAlpha() {
return new TryLookupIfPropertyAlpha();
}
@LookupUnlessProperty(name = "service.alpha.enabled", stringValue = "true")
@ApplicationScoped
public TryLookupIfProperty tryLookupIfPropertyBeta() {
return new TryLookupIfPropertyBeta();
}
}
- 打開剛才的BeanInstanceSwitchTest.java,setUp方法中將service.alpha.enabled的值設為true。
@BeforeAll
public static void setUp() {
System.setProperty("service.alpha.enabled", "true");
}
- 運行單元測試,如下圖,符合預期。
- 現在把service.alpha.enabled的值設為false,單元測試不通過,提示返回值是TryLookupIfPropertyBeta,這也是符合預期的,證明LookupUnlessProperty已經生效了。
- 此刻您可能會好奇,如果配置項service.alpha.enabled不存在會如何,咱們將setUp方法中的System.setProperty這段代碼刪除,這樣配置項service.alpha.enabled就不存在了,再次執行單元測試,發現SelectBeanConfiguration類的tryLookupIfPropertyAlpha和tryLookupIfPropertyBeta兩個方法都沒有執行,導致沒有TryLookupIfProperty類型的bean。
- 這時候您應該發現了一個問題:如果配置項service.alpha.enabled不存在的時候如何返回一個默認bean,以避免找不到bean呢?
- LookupIfProperty和LookupUnlessProperty都有名為lookupIfMissing的屬性,意思都一樣:指定配置項不存在的時候,就執行注解所修飾的方法,修改SelectBeanConfiguration.java,如下圖黃框所示,增加lookupIfMissing屬性,指定值為true(沒有指定的時候,默認值是false)。
- 再次運行單元測試,如下圖,盡管service.alpha.enabled不存在,但lookupIfMissing屬性起了作用,SelectBeanConfiguration.tryLookupIfPropertyAlpha方法還是執行了,于是測試通過。
IfBuildProfile,如果是指定的profile才能使用bean
- 應用在運行時,其profile是固定的,IfBuildProfile檢查當前profile是否是指定值,如果是,其修飾的bean就能被業務代碼使用。
- 對比官方對LookupIfProperty和IfBuildProfile描述的差別,LookupIfProperty決定了是否能被選擇,IfBuildProfile決定了是否在容器中。
# LookupIfProperty,說的是be obtained by programmatic
Indicates that a bean should only be obtained by programmatic lookup if the property matches the provided value.
# IfBuildProfile,說的是be enabled
the bean will only be enabled if the Quarkus build time profile matches the specified annotation value.
- 接下來寫代碼驗證,先寫個接口。
public interface TryIfBuildProfile {
String hello();
}
- 再寫兩個實現類,第一個是TryIfBuildProfileProd.java。
public class TryIfBuildProfileProd implements TryIfBuildProfile {
@Override
public String hello() {
return "from " + this.getClass().getSimpleName();
}
}
- 第二個TryIfBuildProfileDefault.java。
public class TryIfBuildProfileDefault implements TryIfBuildProfile {
@Override
public String hello() {
return "from " + this.getClass().getSimpleName();
}
}
- 再來看IfBuildProfile的用法,在剛才的SelectBeanConfiguration.java中新增兩個方法,如下所示,應用運行時,如果profile是test,那么tryIfBuildProfileProd方法會被執行,還要注意的是注解DefaultBean的用法,如果profile不是test,那么quarkus的bean容器中就沒有TryIfBuildProfile類型的bean了,此時DefaultBean修飾的tryIfBuildProfileDefault方法就會被執行,導致TryIfBuildProfileDefault的實例注冊在quarkus容器中。
@Produces
@IfBuildProfile("test")
public TryIfBuildProfile tryIfBuildProfileProd() {
return new TryIfBuildProfileProd();
}
@Produces
@DefaultBean
public TryIfBuildProfile tryIfBuildProfileDefault() {
return new TryIfBuildProfileDefault();
}
- 單元測試代碼寫在剛才的BeanInstanceSwitchTest.java中,運行單元測試是profile被設置為test,所以tryIfBuildProfile的預期是TryIfBuildProfileProd實例,注意,這里和前面LookupIfProperty不一樣的是:這里的TryIfBuildProfile直接注入就好,不需要Instance<T>來注入。
@Inject
TryIfBuildProfile tryIfBuildProfile;
@Test
public void testTryLookupIfProperty() {
Assertions.assertEquals("from " + TryLookupIfPropertyAlpha.class.getSimpleName(),
service.get().hello());
}
@Test
public void tryIfBuildProfile() {
Assertions.assertEquals("from " + TryIfBuildProfileProd.class.getSimpleName(),
tryIfBuildProfile.hello());
}
- 執行單元測試,如下圖,測試通過,紅框顯示當前profile確實是test。
- 再來試試DefaultBean的是否正常,修改SelectBeanConfiguration.java的代碼,如下圖紅框,將IfBuildProfile注解的值從剛才的test改為prod,如此一來,再執行單元測試時tryIfBuildProfileProd方法就不會被執行了,此時看tryIfBuildProfileDefault方法能否執行。
- 執行單元測試,結果如下圖,黃框中的內容證明是tryIfBuildProfileDefault方法被執行,也就是說DefaultBean正常工作。
UnlessBuildProfile,如果不是指定的profile才能使用bean
- UnlessBuildProfile的邏輯與IfBuildProfile相反:如果不是指定的profile才能使用bean。
- 回顧剛才測試失敗的代碼,如下圖紅框,單元測試的profile是test,下面要求profile必須等于prod,因此測試失敗,現在咱們將紅框中的IfBuildProfile改為UnlessBuildProfile,意思是profile不等于prod的時候bean可以使用。
- 執行單元測試,如下圖,這一次順利通過,證明UnlessBuildProfile的作用符合預期。
IfBuildProperty,如果構建屬性匹配才能使用bean
- 最后要提到注解是IfBuildProperty是,此注解與LookupIfProperty類似,下面是兩個注解的官方描述對比,可見IfBuildProperty作用的熟悉主要是構建屬性(前面的文章中提到過構建屬性,它們的特點是運行期間只讀,值固定不變)。
# LookupIfProperty的描述,如果屬性匹配,則此bean可以被獲取使用
Indicates that a bean should only be obtained by programmatic lookup if the property matches the provided value.
# IfBuildProperty的描述,如果構建屬性匹配,則此bean是enabled
the bean will only be enabled if the Quarkus build time property matches the provided value
- 限于篇幅,就不寫代碼驗證了,來看看官方demo,用法上與LookupIfProperty類似,可以用DefaultBean來兜底,適配匹配失敗的場景。
@Dependent
public class TracerConfiguration {
@Produces
@IfBuildProperty(name = "some.tracer.enabled", stringValue = "true")
public Tracer realTracer(Reporter reporter, Configuration configuration) {
return new RealTracer(reporter, configuration);
}
@Produces
@DefaultBean
public Tracer noopTracer() {
return new NoopTracer();
}
}
- 至此,基于多種注解來選擇bean實現的學習已經完成,依靠配置項和profile,已經可以覆蓋多數場景下bean的確認,如果這些不能滿足您的業務需求,接下來的文章咱們繼續了解更多靈活的選擇bean的方式。
責任編輯:姜華
來源:
今日頭條