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

自上次 帖子（关于 1.0 M1）以来，许多功能得到了改进或添加（大约 1.0 M1）；我将在未来的文章中详细介绍它们（还有详细介绍该库的参考 文档），所以这里我只列举几项：

- 一致性

我们希望提供一个强大、简单且一致的编程模型。这就是为什么 Spring Dynamic Modules 构建在 Spring 之上，并使用其经过验证的概念、可靠性和普遍性。

- 高度非侵入性

使用 Spring DM 的推荐方法是*不要*在代码中使用其类，或者在捆绑包清单中导入它们。如果您不在代码中使用 Spring，而仅用于应用程序配置，则相同的规则适用。Spring DM 会为您创建应用程序上下文，因此您无需依赖 Spring 或 Spring DM。而且不用担心自定义命名空间或 XML 模式等问题——我们已经解决了它们。

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

这是 Spring DM 最重要的功能之一——能够像处理*普通* Bean 一样与 OSGi 服务进行交互。您可以在不编写任何代码的情况下发布和消耗 OSGi 服务；我们会为您处理动态性——并且您拥有完全的控制权（未来将提供更多关于此的信息）。

- 更智能的集成测试框架

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

- 简单的捆绑包交互

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

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

在 OSGi 中，应用程序被分解成各种相互依赖服务的模块（也称为捆绑包）。这会在模块之间创建依赖关系树，这在启动和关闭过程中很重要。传统上，这可以通过根据依赖顺序安装和启动捆绑包来解决，但这并不能完全解决问题。如 OSGi 规范所建议的，耗时初始化的 OSGi 服务（如连接池）应该依赖于与启动和停止捆绑包所用的线程不同的线程。这意味着，如果一个捆绑包已启动，并不意味着它的服务已经可用。并非所有应用程序都已准备好在启动时等待其所需的服务——实际上，很少有应用程序这样做。这意味着捆绑包将失败，因为它依赖于在几毫秒后发布的*其他*服务（OSGi 默认情况下是一个 VM 内平台，事物*非常*快速地发生）。

这种行为并不少见——实际上，在多核平台上，多个捆绑包在启动时很常见。Spring DM 通过确定依赖关系（来自 Spring 配置）并在创建应用程序上下文之前等待它们可用，来解决此问题。在关闭时将进行类似的流程，Spring DM 将根据依赖顺序停止上下文，因此您不必担心启动或停止您的捆绑包。

- 无线程依赖等待

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

然而，在一个 OSGi 平台上，可以有（并且将会有）多个模块（很容易达到几十个）——每个模块使用一个等待线程根本无法扩展。我们努力改进了这个模型，并且我认为我们提供了一个非常好的解决方案——为等待过程根本*不*使用线程。这意味着，无论部署了 3 个捆绑包还是 300 个，只要您的模块没有实际启动，就不会花费任何 CPU 时间。

 

Spring Dynamic Modules 不仅仅是“spring-ify”一个 API，而是处理一个不同的运行时环境。

 

在工具方面，Spring IDE 支持 Spring DM 命名空间，并且（感谢 Christian）还为 Eclipse PDE 提供了 Spring-DM 特定的 目标，这些功能在 Spring IDE 的 nightly builds 中可用（有关安装和使用插件的更多信息，请参阅参考文档 可用）。

 

未来方向

 

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

Web 支持

OSGi 平台提供了一个专用的 Http Service，但使用它需要编写代码。诸如资源加载、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 集成测试”