從Spring Monolith應用程序遷移到OSGI

Question

在過去的十年中，我們一直在使用Spring作為依賴注入來構建兩個應用程序套件。 我們還使用spring-batch和spring-amqp。 現在，我們正在尋求遷移到OSGI，以便將我們的整體應用程序分成多個包，從而使我們更加敏捷。 這兩個套件是Web應用程序，被部署為兩個單獨的war文件。 我們希望將Apache Karaf用作我們的OSGI運行時。

Spring-DM已經死了，看來我們將不得不轉換一切以使用Blueprint進行依賴注入。

我的問題是我們如何逐步做到這一點？ 立即轉換所有這些幾乎是不可能的。 似乎一個捆綁包仍然應該能夠使用Spring DI並擁有自己的應用程序上下文，只要我們有責任向捆綁包激活器中的服務注冊表公開我們想要的任何服務，但是我不確定是否有就像交易管理一樣，這是我們會失去的魔力。

任何對此的指導將不勝感激。

Answer 1

您可能要考慮使問題看起來更大，並改用DS而不是Blueprint ...為了真正利用OSGi模型，DS在所有方面都遠遠優於Blueprint。 實際上，在第一個障礙之后，您將取得更大的進步，您的收益也會更高。 盡管Blueprint使Spring可以在OSGi上使用，但它從未“脫穎而出” OSGi。

對於策略，請讓您的Spring應用程序作為一個捆綁包保持活動狀態，然后逐步將其移出。 即大象的方法。

OSGi提供的最大收益可總結如下：

• 確保模塊具有僅處理協作的服務API。 也就是說，每個服務API都應該是一個故事/場景，參與者是如何協同工作的，而不是他們如何形成和配置的。
• 讓Configuration Admin進行配置。 即從不公開配置API。 在OSGi中，您注冊的是實例，而不是仍需要配置的東西。

確保您真的了解帶有服務的OSGi模型。 您可能想看看利用OSGi的OSGi enRoute 。

Answer 2

我建議您看看blueprint-maven-plugin 。 它允許使用CDI和JEE注釋的子集來定義注入以及事務和持久性。 該插件在構建時創建藍圖xml，然后可由karaf執行。 最大的好處是spring也支持這些注釋。 因此，您可以使用spring過渡並並行發布到生產環境。

我在這里有一個完整的基於注釋的藍圖和JPA示例。

使用該插件，我在並行開發和發布時遷移了一個中型項目。 如果您在使用插件時需要更多建議，我一定會提供幫助。