Spring - OSGi集成项目Milestone 1发布

• 关 键 词：
• spring
• 配置
• 进程

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。正如我所说过的一样，这项功能非常酷，你应该亲身体验一下来确信这一点。甚至没有任何容器曾经向它靠拢过。

原文链接：http://www.infoq.com/news/2007/04/springosgi

转载保留：http://www.qqread.com/news/f310010.html 更多内容请看Spring开源框架技术、spring发展简介、Spring开发技术篇专题，或进入讨论组讨论。

【深 度 阅 读】 相 关 文 章

• Spring入门书籍
• Spring 中文开发手册
• 实现基于Spring框架应用的权限控制系统
• Spring 总结XML配置的十二个最佳实践