Spring - OSGi 项目的第一个里程碑版本近期刚刚发布，该项目提供了将 Spring 应用部署到 OSGi 环境的支持。由于 OSGi 的重点在于模块的动态化管理，这给 Spring 的集成团队带来了很多特殊的挑战。
采用 OSGi 的最大挑战之一就是处理其动态本质。在应用程序中，服务（以简单对象实例形式存在）加进来移出去，而你的应用必须对其进行处理。解决方法并不是很直截了当的，需要根据不同的实际情况而采用不同的处理方式，并且如同异常处理和事务处理一样，需要应用级别的全局作用域。在模块化的过程中，类装载方式的限制会显得更加突出，而这种限制与 AOP 的合并则会带来更大的麻烦：开发人员不得不另觅蹊径，但这样一来，就会把 OSGi 带来的好处扔的一干二净。这只是我们在 Spring-OSGi 里面正在处理的事情中的很少一部分而已，在最终版本中，肯定会与 OSGi 平滑相接。
这个发布版的部分核心特性包括：
OSGi 应用上下文（OSGi Application Context）
尽管 OSGi 采用的是基于 bundle——也就是独立模块——的架构，但 Spring-OSGi 增加了应用级别的上下文，这样开发人员就可以通过它对存放整个应用的 OSGi 上下文进行访问。
对资源的抽象（Resource Abstraction）
OSGi 向 classpath 中加入了一个抽象层，在该层中有一个 URL scheme，它会根据实现的不同而变化。Spring-OSGi 对这个 scheme 进行了封装，并提供了一个很轻便的查询接口。
动态服务支持（Dynamic Service Support）
通过 XML 配置，把任何对象转换成 OSGi 服务都是轻而易举的事情。
集成测试（Integration Testing）
Spring-OSGi 在 JUnit 的基础上，添加了一个用于测试的微架构，这样一来，从 IDE 中运行需要在容器中执行的测试就会更加简单了。
Hal Hilderbrand 指出，对 JUnit 的支持尤其引人注目：
从根本上说，任何有关容器内测试（In-container Testing）的问题都可以归结于如何将测试在容器内运行起来。我们首先必须要配置并启动容器，当然，需要部署测试代码（在 OSGi 容器中，则需要部署测试场景所需的 bundle），然后就剩下 JUnit 测试了。接下来我们必须要从容器外触发测试的运行，并通过某些方式得到测试的运行结果。Costin 的框架很漂亮的解决了这一点，它在同一个进程中配置并启动 OSGi 容器，同时把所有的 JUnit 测试类包装到一个自动生成的 OSGi bundle 中。其结果就是，现在的容器内测试可以完全和任何 JUnit 测试一样运行 - 用 Ant 或者 Maven，或任何一款你所偏爱的 IDE。正如我所说过的一样，这项功能非常酷，你应该亲身体验一下来确信这一点。甚至没有任何容器曾经向它靠拢过。
译者简介：李剑，中国Eclipse 社区插件开发版版主，在JavaEye 拥有 RCP 专栏, 北航软件工程硕士。现就职于 Ethos ，热衷于设计模式，敏捷软件开发的研究与实践。为 InfoQ 中文站贡献内容，请邮件至 china-editorial@infoq.com 。
暂无签名
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
评论