从 Spring 单体应用程序迁移到 OSGI

Question

在过去的 10 年里，我们一直在使用 Spring 作为依赖注入来构建两套应用程序。我们还使用 spring-batch 和 spring-amqp。我们现在正在寻求迁移到 OSGI，以便可以将我们的单体应用程序分成多个包，从而使我们更加敏捷。这两个套件是 Web 应用程序，并部署为两个单独的 war 文件。我们希望使用 Apache Karaf 作为我们的 OSGI 运行时。

Spring-DM 已死，看来我们将不得不转换一切以使用蓝图进行依赖注入。

我的问题是我们如何逐步做到这一点？一次转换所有这些几乎是不可能的。只要我们负责在捆绑激活器中向服务注册表公开我们想要的任何服务，似乎一个捆绑包仍然应该能够使用 Spring DI 并拥有它自己的应用程序上下文，但我不确定是否存在是某种我们会失去的魔法，比如事务管理。

对此的任何指导将不胜感激。

Answer 1

我建议你看看blueprint-maven-plugin。它允许使用 CDI 和 JEE 注释的子集来定义注入以及事务和持久性。该插件在构建时创建蓝图 xml，然后可以由 karaf 执行。最大的优点是这些注解也被spring支持。因此，您可以使用 spring 转换并并行发布到生产环境。

我在这里有一个完整的例子Annotation based blueprint and JPA。

使用这个插件，我迁移了一个中型项目，同时它是并行开发和发布的。如果您在使用插件时需要进一步的建议，我当然可以提供帮助。

Answer 2

您可能要考虑使问题出现更大，并切换到 DS 而不是 Blueprint ... 要真正利用 OSGi 模型，DS 在各方面都远远优于 Blueprint .实际上，经过第一关，你会取得更大的进步，你的收获会更高。尽管 Blueprint 在 OSGi 上提供了 Spring，但它从未“获得”OSGi。

对于策略，将您的 Spring 应用程序作为一个单独的包保持活力，并逐渐将其移出。 IE。大象走近了。

OSGi提供的最大收获可以总结如下：

• 确保模块具有仅处理协作的服务 API。 IE。每个服务 API 都应该是参与者如何协同工作的故事/场景，而不是他们如何存在和配置。
• 让配置管理员进行配置工作。 IE。永远不要暴露配置 API。在 OSGi 中，您注册的是实例，而不是仍然需要配置的东西。

确保您真正了解带有服务的 OSGi 模型。您可能想看看OSGi enRoute，它充分利用了 OSGi。