的相關性選擇了使用配置屬性

在一個網絡管理系統，這是完全的OSGi基於並具有嚴重的就業服務層SOA概念，它決定將NE管理模塊DS部件。
有一個DS組件用於跟蹤網絡資源的配置子代理，當時間合適時，它會根據Neil's article通過出廠配置將管理組件配置爲關注該資源。
組件集未知，但其配置工廠PID由安裝管理組件的專用軟件包發佈。
讓我們說有一些當中這些管理組件靜態，不願和強制性的依賴，例如C2需要C1。由於NMS需要添加許多資源，因此可能有許多C1和C2的實例。因此，C2必須綁定到其匹配C1。
此選擇的標準是一個關鍵，例如resource-key，它由配置代理爲每個資源生成，並通過其（工廠）配置屬性提供給每個組件。

現在，這裏是我的問題：

問：由於配置屬性是唯一部件的激活後可用，怎麼能C2綁定到前一個正確的C1被激活，因爲他們的關係的本質是什麼？

我知道這個問題有不同的口味，有一些機智的答案，如Dynamic target queries in OSGi with DS和here。但是，所有這些答案中缺少的是這樣一個事實，即有些情況下組件的每個實例的動態配置都不是已知的，或者至少在它被激活之前是不知道的。

建議： 因爲我們必須解決這個問題，只有優雅和OSGi的可接受答案，我能想到的是介紹在參考綁定時間允許這樣的事情對於動態宏擴展C2：

@Reference(target="(resource-key=${resource-key})") 
protected void bindC1(C1 c1) 
{ 
    // some binding code 
}

我們選擇了堅持春分DS暫且（！是的，我知道的），因此，我已經修補了IR SCR現在C2會結合的C1適當情況下與resource-key財產「通過使用C2擴大${resource-key-value} S」自己的一套配置匹配的C2。該值在C2.bindC1()內尚未（可）訪問。

我想知道爲什麼這樣一個方便的設施從我測試過的每個SCR中都沒有。我在這裏展示的內容很可能會擴展到使用各種來源，而不僅僅是組件的配置屬性。但爲什麼至少沒有證據表明此類功能的正式提案？請賜教！

來源

2017-02-14 Hamid Nazari

我沒有看到你需要這樣的功能。由於您通過組件屬性提供resource-key，爲什麼不只是提供C1引用的目標屬性C1.target（請參見DS規範中的112.6.2.1），它以同樣的方式引用資源鍵值？

C1.target = (resource-key=xxx)

的C1.target組件屬性的值將覆蓋在C1參考註釋的target信息。

確定值(resource-key=xxx)比xxx稍微複雜一些，但這比一些宏擴展功能要容易得多。

來源

2017-02-14 15:51:22

顯然是因爲解耦;我們（配置者代理）不想強制組件如何選擇它們的依賴關係。他們可以根據自己的意願自由選擇他們的「目標」。這是我們希望組件具有的另一種靈活性。爲他們提供'目標'限制他們的發展。 –

此外，配置代理不需要知道組件的所有細節，據推測C2'需要'C1'。它只是爲他們提供了一個非常基本但重要的配置，以便他們可以綁定他們的依賴並變得活躍。 –

我的意思是，在你的例子中，你正在設置資源密鑰屬性，它的值選擇一些C1服務到C2的配置中。如果你可以做到這一點，你也可以輕鬆地將其值選擇一些C1服務的C1.target屬性設置爲C2的配置。除了不需要發明一些宏代替語言之外，沒有實際的區別。 –

的相關性選擇了使用配置屬性

回答

相關問題