1

想象一下，您想在 Java 中拥有一个高度模块化的 Web 应用程序。组件也已经在使用 Spring 框架。一些组件仅涵盖纯逻辑，而其他一些组件还带有一些 HTML 演示 GUI。该应用程序与 Portlet 不兼容，但我们需要动态菜单来提升已安装模块的列表以及指向页面或 REST API 的链接。由于它是 Java，因此建议使用 OSGI，但我对 OSGI 的最新功能（过去几年引入）感到非常困惑，我有几个问题：

  • 现在 OSGI 不仅是模块管理系统，也是 IoC 容器！它几乎包含许多 Spring IoC 特性的等效注释。那么我们如何在 OSGI 中使用启用 Spring 的模块呢？我们能否在新设计中取消 Spring 并完全依赖 OSGI？或者对于模块内的依赖注入，我们可以使用 Spring，对于模块上的依赖注入，我们可以使用 OSGI？

  • 对于现实生活中的大型应用程序，我们有两种选择：在应用程序容器（例如 Tomcat）中使用嵌入式 Felix 或在 KARAF 中使用应用程序容器的 OSGI 捆绑包（Jetty 或 Tomcat）。哪种方法更好？哪一个更具可扩展性？

4

2 回答 2

1

研究 OSGi 可能会让人感到困惑，因为那里有 15 年的文章和示例——其中很多是有效的，但可能已经过时了。

如果只是将 Spring 用作 IoC 容器，则可以考虑将其移除。如果在您的 OSGi 容器中启用了 DS， OSGi DS会提供@Component和@Reference注释（如 spring Autowire）。新的OSGi 航路项目有一些执行 IoC 和提供 REST 服务的现代示例。

替换更多功能可能需要更多工作。由于 OSGi 中的类加载器差异以及 Spring 项目远离 OSGi，在 OSGi 中运行最新的 Spring 可能无法正常工作。

于 2015-09-17T10:44:08.920 回答
0

OSGi 根本不是 IoC 容器。不过，有一些在 OSGi 上运行的注入支持技术。最重要的是声明式服务和蓝图。并不真正支持 Spring。有一些 Spring DM 支持，但是这段代码没有维护很久。

因此，您应该使用上面两个受支持的 IoC 容器之一。对于 aries 蓝图，我使用 maven-blueprint-plugin 编写了对 CDI 注释的支持。这可能是您转换应用程序的最佳选择。我建议首先将您的 spring 应用程序转换为仅使用 CDI 注释，然后才开始 OSGi 迁移。这样的迁移并不容易。确保你得到一些好的指导和咨询。

如果您的大多数应用程序不是 OSGi 并且您只想在很小的一部分中使用捆绑包，那么在 servlet 容器上嵌入 Felix 是很好的。如果您想为 OSGi 编写整个应用程序，Karaf 会更好。

于 2015-09-16T16:59:42.117 回答