OSGI服務版本控制實踐？

我熟悉OSGI語義版本 - 技術白皮書。但是，我沒有看到針對OSGI服務提出的任何版本控制概念。OSGI服務版本控制實踐？

簡單情況：我提供的服務註冊爲com.services.payments.PaymentService，其中impelemnts方法void makePayment（Integer amount，String accountNo），我打包爲捆綁版本1.0。然後，我使用修改的界面更新服務。我刪除此方法並添加新方法： makePaymentInDifferentWay（Integer amount，String accountNo）並將新服務打包爲版本2.0。在第一個包停止後，客戶端將有第二個服務連接，並且CRASH服務調用，因爲方法簽名不是二進制兼容的。這些情況在處理java包時得到了很好的解決，但是我沒有看到OSGI服務提供的任何版本控制功能。我錯過了什麼嗎？（我知道我可以通過設置服務屬性（如'service.version'）並通過此屬性在客戶端過濾提供的服務，或者直接重命名API包或類名稱來設計版本控制方案，但爲什麼不提供版本控制？也許還有其他一些更爲標準的方式解決方案？也許有一些與服務有關的概念，我根本沒有把握？）

來源

2012-05-17 user1401315

服務是包中的類型和類型。所以服務的版本是包含服務類型的包的版本。當客戶端使用與服務的提供者相同的服務類型包時，OSGi框架只確保向客戶端公開服務。

來源

2012-05-17 16:18:38

客戶端應該在其Import-Package語句（或Require-Bundle）語句，如：

Import-Package: com.services.payments;version="[1.0,2.0)"

，該服務將包導出爲：

Export-Package: com.services.payments;version="1.0.0"

停止第一個包並安裝第二個包後，客戶端將無法解析解析（因爲所需約束com.services.payments;version="[1.0,2.0)"將不會被滿足。如果你有兩個API包，一個包版本爲「1.0.0」，另一個包含版本「2.0.0」，客戶端導入「1.0.0」API，客戶端將不會「看到「服務實施API版本」2.0.0「。

來源

2012-05-17 16:10:14

我想這是軟件包版本控制而不是服務版本控制，因爲通過調用BundleContext.registerService而不是使用Export-Package清單頭來暴露服務。 –

是的，這是軟件包版本控制。問題是關於「服務版本控制」，但據我所知，它更多的是關於服務二進制兼容性，這是通過包/捆綁版本實現的。 –

伊萬得到了這個完全正確。您正在對API進行版本控制，因此理論上您不必關心服務實施版本。起初有麻煩的部分是獨立於封閉罐子版本的軟件包。如果您將jar作爲實現細節，並將其打包爲OSGi中的第一類，則更有意義。 –

OSGI服務版本控制實踐？

回答

相關問題