从 Spring 单体应用程序迁移到 OSGI
Migrating from Spring monolith application to OSGI
在过去的 10 年里，我们一直在使用 Spring 作为我们的依赖注入来构建两套应用程序。我们还使用 spring-batch 和 spring-amqp。我们现在正在寻求迁移到 OSGI，这样我们的单体应用程序就可以分成多个包，这样我们就可以更加敏捷。这两个套件是 Web 应用程序，部署为两个单独的 war 文件。我们希望使用 Apache Karaf 作为我们的 OSGI 运行时。
Spring-DM 已死，看来我们将不得不转换一切以使用蓝图进行依赖注入。
我的问题是我们如何逐步做到这一点？一次将所有这些转换过来几乎是不可能的。似乎一个 bundle 应该仍然能够使用 Spring DI 并拥有它自己的应用程序上下文，只要我们负责将我们想要的任何服务暴露给 bundle 激活器中的服务注册表，但我不确定是否有某种魔法我们会失去，比如事务管理。
任何关于这方面的指导将不胜感激。
我建议你看看blueprint-maven-plugin。它允许使用 CDI 和 JEE 注释的子集来定义注入以及事务和持久性。该插件在构建时创建蓝图 xml，然后可以由 karaf 执行。最大的好处是 spring 也支持这些注释。因此，您可以使用 spring 过渡并并行发布到生产环境。
我这里有一个完整的例子Annotation based blueprint and JPA。
使用这个插件，我在并行开发和发布的同时迁移了一个中型项目。如果您在使用插件时需要进一步的建议，我一定可以提供帮助。
您可能需要考虑使问题显得 更大，并切换到 DS 而不是 Blueprint ...要真正利用 OSGi 模型，DS 更胜一筹到各方面的蓝图。事实上，过了第一关，你会取得更大的进步，你的收获会更高。尽管 Blueprint 使 Spring 在 OSGi 上可用，但它从未 'got' OSGi。
对于策略，请将您的 Spring 应用程序作为一个捆绑包保持活动状态，然后逐渐将其移出。 IE。大象接近。
OSGi提供的最大收获可以总结如下：
- 确保模块具有仅处理协作的服务 API。 IE。每个服务 API 应该是 story/scenario 参与者如何协同工作，而不是它们如何产生和配置。
- 让配置管理员进行配置工作。 IE。永远不要公开配置 APIs。在 OSGi 中，您注册实例，而不是仍然需要配置的东西。
确保您真正了解带有服务的 OSGi 模型。您可能想看看 OSGi enRoute，它充分利用了 OSGi。
在过去的 10 年里，我们一直在使用 Spring 作为我们的依赖注入来构建两套应用程序。我们还使用 spring-batch 和 spring-amqp。我们现在正在寻求迁移到 OSGI，这样我们的单体应用程序就可以分成多个包，这样我们就可以更加敏捷。这两个套件是 Web 应用程序，部署为两个单独的 war 文件。我们希望使用 Apache Karaf 作为我们的 OSGI 运行时。
Spring-DM 已死，看来我们将不得不转换一切以使用蓝图进行依赖注入。
我的问题是我们如何逐步做到这一点？一次将所有这些转换过来几乎是不可能的。似乎一个 bundle 应该仍然能够使用 Spring DI 并拥有它自己的应用程序上下文，只要我们负责将我们想要的任何服务暴露给 bundle 激活器中的服务注册表，但我不确定是否有某种魔法我们会失去，比如事务管理。
任何关于这方面的指导将不胜感激。
我建议你看看blueprint-maven-plugin。它允许使用 CDI 和 JEE 注释的子集来定义注入以及事务和持久性。该插件在构建时创建蓝图 xml，然后可以由 karaf 执行。最大的好处是 spring 也支持这些注释。因此，您可以使用 spring 过渡并并行发布到生产环境。
我这里有一个完整的例子Annotation based blueprint and JPA。
使用这个插件，我在并行开发和发布的同时迁移了一个中型项目。如果您在使用插件时需要进一步的建议，我一定可以提供帮助。
您可能需要考虑使问题显得 更大，并切换到 DS 而不是 Blueprint ...要真正利用 OSGi 模型，DS 更胜一筹到各方面的蓝图。事实上，过了第一关，你会取得更大的进步，你的收获会更高。尽管 Blueprint 使 Spring 在 OSGi 上可用，但它从未 'got' OSGi。
对于策略，请将您的 Spring 应用程序作为一个捆绑包保持活动状态，然后逐渐将其移出。 IE。大象接近。
OSGi提供的最大收获可以总结如下：
- 确保模块具有仅处理协作的服务 API。 IE。每个服务 API 应该是 story/scenario 参与者如何协同工作，而不是它们如何产生和配置。
- 让配置管理员进行配置工作。 IE。永远不要公开配置 APIs。在 OSGi 中，您注册实例，而不是仍然需要配置的东西。
确保您真正了解带有服务的 OSGi 模型。您可能想看看 OSGi enRoute，它充分利用了 OSGi。