這裏之前動態引用的注入是intrested案例片段:阿帕奇菲利克斯 - 如何保證一個激活方法
我們有一些配置類可以有多個實例。它假設我們在一個包中提供多種配置。這是一個範圍。
@Service
@Component
public class SampleConfigurationImpl implements SampleConfiguration {
// declaration of some properties, init method and etc...
}
另外,我們有一個使用這些配置的服務:
@Service
@Component
public class SampleServiceImpl implements SampleService {
@Reference(
referenceInterface = SampleConfiguration.class,
cardinality = ReferenceCardinality.OPTIONAL_MULTIPLE,
policy = ReferencePolicy.DYNAMIC)
private Map<String, SampleConfiguration> sampleConfigurations = new ConcurrentHashMap<>();
private void bindSampleConfigurations(SampleConfiguration sampleConfiguration) {
sampleConfigurations.put(sampleConfiguration.getName(), sampleConfiguration);
}
private void unbindSampleConfigurations(SampleConfiguration sampleConfiguration) {
sampleConfigurations.remove(sampleConfiguration.getName());
}
@Activate
private void init() {
System.out.println(sampleConfigurations.size());
}
}
所以,我可以得到一些保證,在init()方法的調用所有配置都注射(至少當前包的)?也許有一些替代方法來做到這一點。我知道另一個捆綁包可以帶來新的配置,獲得保證是不真實的,但只有一個捆綁包纔有意義。
在實踐中,它可能是在init方法中只有部分配置的情況。特別是如果你遇到幾種類型的配置或者一種服務使用另一種具有動態引用和第一種服務的服務依賴於注入所有東西的事實,那麼情況就更加困難。
最不愉快的是它可以在init方法之前和之後綁定/取消綁定配置。 也許有一種方法可以保證它始終綁定在init方法之後...
我對任何信息感興趣。在兩個問題上得到答案(在之前或之後提供保證)會很好。可能有人經歷過如何解決此類問題,並可以與我分享。
謝謝。
弗蘭克是正確的。動態引用可以在*激活之前,之後或*期間隨時綁定(是,在激活方法執行時,可以從另一個線程同時綁定服務)。這只是動態引用的價格...您可能希望使用帶有貪婪策略的靜態引用。順便說一下,您懷疑您正在使用服務來注入配置。爲什麼不使用用於DS的配置管理綁定,其中配置對象被傳遞到activate方法中? –
謝謝弗蘭克。它可以幫助我,但在這種情況下,我必須考慮到它必須以不同的方式在init方法之前和之後綁定配置(在init方法之前,我不確定是否注入了所有靜態引用,並且需要在init之後推遲它方法)。另外,我必須創建一些未處理的配置隊列,並在init方法處理它之後。它帶來了額外的邏輯來同步這種服務的狀態以反映新配置的綁定。我同意,這聽起來很奇怪。 – Alex
@NeilBartlett也感謝你。我是正確的,通過配置管理綁定DS您意味着爲SampleServiceImpl添加configurationPid =「com.sample.SampleConfigurationImpl」屬性?在這種情況下,它創建N個服務器,其中N是配置的數量。當我需要將此服務注入到另一個組件時,它不適合。爲什麼不?我希望有一些服務可以處理請求,並且可以決定它需要使用哪些配置以用於特定參數。聽起來很合理。所以,即使我調用當前包的servlet,我也不確定所有配置都是綁定的。 – Alex