我很高兴地报告（和 Adrian 一起），经过 3 个里程碑版本和 2 个候选发布版本，Spring Dynamic Modules（之前称为 Spring OSGi）1.0 已发布。

自我的上一篇文章（关于 1.0 M1）以来，许多功能得到了改进或新增；我将在未来的文章中详细介绍它们（还有详细解释该库的参考文档），所以这里只列举一些

- 一致性

我们希望提供一个强大、简单且一致的编程模型。这就是 Spring Dynamic Modules 构建在 Spring 之上并利用其成熟的概念、可靠性和普遍性的原因。

- 高度非侵入性

使用 Spring DM 的推荐方式是不要在您的代码中使用其类，也不要在您的 Bundle Manifest 中导入它们。如果您只将 Spring 用于应用程序配置而不用于代码，同样的规则也适用。Spring DM 会为您创建应用程序上下文，因此您无需依赖 Spring 或 Spring DM。并且不必担心自定义命名空间或 XML Schema 之类的事情 - 我们已经涵盖了这些。

- OSGi 服务动态生命周期管理

这是 Spring DM 最重要的特性之一 - 能够像处理普通 Bean 一样与 OSGi 服务交互。您无需编写任何代码即可发布和消费 OSGi 服务；我们将为您处理动态性 - 并且您拥有完全的控制权（未来将对此进行更多介绍）。

- 更智能的集成测试框架

由于我们在内部广泛使用了 Spring-DM 集成测试，我们改进了默认配置、Maven 集成，并使自动 Manifest 生成比以前更快、更智能。例如，框架会自动确定测试 Bundle 中可用的类，并且不会为其生成导入项。

- 简单的 Bundle 交互

Andy Piper (博客) 添加了一种简单、声明式的方式，可以根据模块生命周期和 Spring Bean 依赖关系来安装/启动/停止/更新 Bundle。

- 受管的启动/关闭上下文创建

在 OSGi 中，应用程序被分解为各种模块（也称为 Bundle），这些模块相互依赖服务。这会在模块之间形成一个依赖树，这在启动和关闭过程中变得很重要。传统上，可以通过按照依赖顺序安装和启动 Bundle 来解决此问题，但是，这并不能完全解决问题。正如 OSGi 规范所建议的，初始化时间较长的 OSGi 服务（例如连接池）应该依赖于与启动和停止 Bundle 所使用的线程不同的线程。这意味着如果一个 Bundle 启动了，并不意味着其服务也可用了。而且不是每个应用程序都准备好在启动时等待其所需的服务 - 事实上，很少有应用程序会这样做。这意味着一个 Bundle 会失败，因为它依赖于几毫秒后才发布的服务（OSGi 默认是一个虚拟机内平台，事情发生得非常快）。

这种行为并不少见 - 事实上，在具有多个 Bundle 的多核平台上启动时非常常见。Spring DM 通过确定依赖关系（来自 Spring 配置）并在它们可用后才创建应用程序上下文来解决这个问题。在关闭时也会使用类似的过程，Spring DM 将根据其依赖顺序停止上下文，因此您无需担心启动或停止您的 Bundle。

- 无线程依赖等待

在讨论依赖机制时，不得不提及 Hal Hildebrand 实现的用于依赖等待的“无线程”方法（我知道这听起来有点像矛盾修饰法 - 我们正在为其寻找一个更华丽的名称）（请参阅他的博客）。由于各种服务需要可用才能使模块正常启动，因此需要某种形式的等待/监控，这传统上意味着使用线程。

然而，在一个 OSGi 平台上可以有（并且将会有）多个模块（很容易就几十个） - 为每个模块使用一个等待线程根本无法扩展。我们努力改进的一个方面就是这个模型，我相信我们提供了一个非常好的解决方案 - 在等待过程中根本不使用线程。这意味着无论部署 3 个 Bundle 还是 300 个，除非您的模块实际启动，否则不会消耗 CPU 时间。

 

Spring Dynamic Modules 不仅仅是将 API “Spring 化”，更重要的是处理不同的运行时环境。

 

在工具方面，Spring IDE 支持 Spring DM 命名空间，并且（感谢 Christian）还为 Eclipse PDE 提供了 Spring-DM 特定的目标，这是 Spring IDE 每夜构建版本中的可用功能（有关安装和使用该插件的更多信息可在参考文档中找到）。

 

未来方向

 

既然 1.0 已经发布，下一步是什么？还有很多领域需要涵盖

Web 支持

OSGi 平台提供了专用的 Http 服务，但使用它需要编写代码。资源加载、JSP 生成和部署等事情可以显著简化。这是 1.1 版本的主要重点领域。

持久化

现代持久化工具提供了高级功能，例如延迟加载，这些功能依赖于类生成和代理，从而突破了 OSGi 环境强制执行的模块化边界。我们希望解决这个问题，并且像 Web 支持一样，无论使用纯 JDBC 还是/或 ORM 工具，都能提供流畅的体验。

AOP

在持久化问题之后，我们正在寻找在 OSGi 内部进行通用 AOP 的解决方案。这是一个难题，要正确实现，需要 OSGi 平台内部的支持。好消息是像 Equinox Aspects 这样的项目已经开辟了道路，并且 OSGi 企业专家组 (EEG) 也已注意到这个问题。

 

废话不多说

 

如果您想了解更多关于 Spring Dynamic Modules 的信息，请查看项目页面和参考文档，并务必使用我们的邮件列表（论坛即将推出）。此外，最近我们制作了一些关于 OSGi/Spring DM 的截屏视频，可在 Spring DM 主页上找到。第一个视频（由两部分组成），由本人亲自制作，展示了如何快速创建项目以使用 Spring DM 进行集成测试。
为什么选择集成测试？因为使用 Spring DM 进行集成测试是一个非常简单快速的过程，也是学习 OSGi（尤其是在模块化方面）的非常有效的方式。

将来会有更多截屏视频 - 只需告诉我们您想看什么，我们将根据请求数量进行相应安排。

事不宜迟，请看“使用 Spring DM 进行 OSGi 集成测试”