Spring - OSGi集成项目Milestone 1发布

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中文站贡献内容，请邮件至[email protected]。