OSGi應用程序修補策略

Question

什麼是修補OSGi容器的適當機制。

 1) Should the bundles (binaries/jars) have the same name as the old ones then: 
      a. Replace the bundle with the with the new bundle (manifest has been 
       modified to reflect the new version) in the plug-ins folder and, 
      b. Invoke update <bundle id> <bundle name>. 
     2) Or Should the bundles have version information encoded in the file name 
      a. Copy the new bundle to the plug-ins folder 
      b. Invoke update <bundle id> file:plugins/<new Bundle name> 
     3) Or other alternatives, possibly an OBR (not sure of the pros and cons) also 
     we may be constrained by the amount of work involved in retrofitting an OBR. 

有一兩件事我注意到的是，在某些情況下，一個包文件（貌似改名JAR）下的特定包的「數據根」被創建。這種情況在所有情況下都會在更新被調用時發生，或者僅在特定情況下發生。

有沒有關於上述的建議，優點，缺點等。還是有更好的選擇？基本上我的想法是，將原始二進制文件替換爲補丁二進制代碼會很好，這是從OSGi上下文的一個好主意嗎？

我們使用的是Equinox OSGi容器。

乾杯，

Answer 1

我自己會建議你做這個：

1.分割你的API（Java的接口），並以單獨的電纜束您的實現。

這種方式如果只有實現更改API保持「活動」，從而防止OSGI服務被關閉。服務由接口引用。當然你的服務消費者應該能夠處理（暫時）不存在的服務。

2.有一個明確的捆綁命名方案。

我會使用捆綁jar文件名中的版本。您必須區分文件系統中的jar和使用文件名中的版本來幫助很多。另外，如果你不使用版本，我會擔心在運行時覆蓋罐子。理論上它應該起作用，但你永遠不知道。如果你有版本，你不會覆蓋舊的罐子。

3.在Manifest中使用版本。

此外，您應該使用Manifst中的版本屬性。對於你來說這顯然比你的OSGI容器跟蹤你的包要少。

---

你成功安裝了所有新的包後，我會建議你刪除舊的。如果您在文件名中使用了版本，這應該相當容易。如果你離開舊罐子，你可能會遇到較慢的啓動時間。這是因爲雖然您的容器不使用捆綁包，但他必須加載並檢查它們。而且他們還生活在你的班級路線中，並可能增加衝突的風險。

我希望能幫助你一點。這是一個很好的問題！也許一些更有經驗的人也會發布建議:)我想聽聽其他人的做法。