尊敬的 Spring 社区：

在过去的几个月里，我一直在与各种客户合作，参与使用 Google Web Toolkit [GWT] 的项目。我喜欢 GWT，主要是因为它的 Java 到 javascript 编译器。这是打开大门，让普通的 Java 开发人员无需学习新语言即可创建 RIA 的关键。

我一直都是测试驱动开发的粉丝，令我失望的是，起初看起来 TDD 和 GWT 似乎无法协同工作。

测试 GWT 代码有点问题。问题的核心是 GWT 代码在运行之前会被编译成 javascript。在许多情况下，GWT.create() 语句……

在学习 OSGi 时，首先要学习的概念之一是“捆绑包”的概念。在本篇文章中，我想更仔细地了解捆绑包究竟是什么，以及如何将一个普通的 jar 文件转换为 OSGi 捆绑包。所以，事不宜迟，

什么是捆绑包？

OSGi 规范将捆绑包描述为“模块化的单元”，它“由 Java 类和其他资源组成，这些资源 together 可以为最终用户提供功能”。到目前为止还不错，但是捆绑包究竟是什么？再次引用规范：

捆绑包是一个 JAR 文件，它

• 包含 [...] 资源
• 包含一个描述 JAR 文件内容并提供有关捆绑包信息的清单文件。
• 可以在 JAR 文件的 OSGI-OPT 目录或其子目录之一中包含可选文档。

简而言之，一个捆绑包 = jar + OSGi 信息（在 JAR 清单文件中指定 - META-INF/MANIFEST.MF），不需要额外的文件或预定义的文件夹布局。这意味着从 jar 创建捆绑包所需做的就是向 JAR 清单添加一些条目。

OSGi 元数据

OSGi 元数据由清单条目表示，这些条目指示 OSGi 框架捆绑包提供和/或需要什么。规范指出了大约 20 个清单头，但我们只看看最常用的那些。

Export-Package

顾名思义，此标题指示导出哪些包（在捆绑包中可用），以便其他捆绑包可以导入它们。*只有*标题指定的包才会被导出，其余的将是私有的，并且在包含捆绑包之外不可见。

Import-Package

类似于Export-Package，此标题指示捆绑包导入的包。同样，*只有*此标题指定的包才会被导入。默认情况下，导入的包是必需的 - 如果导入的包不可用，则导入捆绑包将无法启动。

Bundle-SymbolicName

Bundle-Name

Bundle-Activator

Bundle-Classpath

Bundle-ManifestVersion

以下是一个示例，摘自使用上面提到的某些标题的 Spring 2.5.x 核心捆绑包清单

 
Bundle-Name: spring-core 
Bundle-SymbolicName: org.springframework.bundle.spring.core 
Bundle-ManifestVersion: 2 
Export-Package:org.springframework.core.task;uses:="org.springframework.core,org.springframework.util";version=2.5.1 org.springframework.core.type;uses:=org.springframework.core.annotation;version=2.5.1[...] 
Import-Package:org.apache.commons.logging,edu.emory.mathcs.backport.java.util.concurrent;resolution:=optional[...] 

大多数情况下，用于 OSGi 元数据的操作很可能花在 Export/Import 包条目上，因为它们描述了捆绑包（即模块）之间的关系。在包方面，没有什么是不言自明的 - 只有提到的包才会被导入/导出，其余的不会。这也适用于子包：导出org.mypackage将*仅*导出此包，而不会导出其他任何内容（例如org.mypackage.util）。导入也是如此 - 即使某个包在 OSGi 空间中可用，除非某个捆绑包明确导入它，否则该捆绑包将看不到它。

总而言之，如果捆绑包 A 导出包 org.mypackage，而捆绑包 B 想使用它，那么捆绑包 A 的META-INF/MANIFEST.MF应该在其Export-Package标题中指定该包，而捆绑包 B 应该将其包含在其Import-Package条目中。

包注意事项

导出相当简单，但导入稍微复杂一些。应用程序通常会通过搜索环境中的某些库并仅使用可用的库来很好地降级，或者库会包含用户不使用的代码。此类示例包括日志记录（使用 JDK 1.4 或 Log4j）、正则表达式（Jakarta ORO 或 JDK 1.4+）或并发实用程序（JDK 5 中的 java.util 或backport-util-concurrent库用于 JDK 1.4）。

用 OSGi 术语来说，依赖于基于其可用性的包转换为*可选*Package-Import。您已经在前面的示例中看到过这样的包。

由于在 OSGi 中，可以存在多个相同类的版本，因此最佳做法是在导出和导入包时都指定类包的版本。这是通过version属性完成的，该属性在每个包声明后添加。OSGi 支持的版本格式为 <major>.<minor>.<micro>.<qualifier>，其中major、minor和micro是数字，而qualifier是字母数字。

版本的含义完全取决于bundle提供者，但是，建议使用流行的编号方案，例如Apache APR项目中的方案，其中

• <major> - 表示重大更新，不保证任何兼容性
• <minor> - 表示更新，保持与旧的次要版本的兼容性
• <micro> - 从用户的角度来看，表示不重要的更新，完全向前和向后兼容
• <qualifier> - 是用户定义的字符串 - 它没有广泛使用，可以为版本号提供额外的标签，例如构建编号或目标平台，没有标准化的含义

默认版本（如果属性缺失）为“0.0.0”。

虽然导出的包必须指示特定版本，但导入者可以使用数学区间表示法指示一个范围 - 例如

[1.0.4, 2.0) 将匹配版本1.0.42及更高版本，直到2.0（不包括）。请注意，仅指定版本而不是区间将匹配大于或等于指定版本的全部包，也就是说

Import-Package: com.mypackage;version="1.2.3"

等同于

Import-Package: com.mypackage;version="[1.2.3, ∞)"

最后一点提示，确保始终在指定版本时使用引号，无论它是范围还是单个版本。

使用OSGi元数据

现在我们已经了解了一些关于bundle的信息，让我们看看有哪些工具可以用来将现有的jar文件转换为osgi格式。

手工操作

不建议采用这种DIY方法，因为拼写错误和多余的空格很容易混入并导致清单文件失效。即使使用智能编辑器，清单文件的格式本身也可能导致一些问题，因为它每行最多只能有72个空格，如果超过这个限制，可能会导致一些难以理解的问题。手动创建或更新jar文件不是一个好主意，因为jar格式要求META-INF/MANIFEST.MF条目必须是存档中的第一个条目 - 如果不是，即使它存在于jar文件中，清单文件也不会被读取。手动方法只推荐在没有其他选择的情况下使用。

但是，如果真的需要直接处理清单文件，则应使用可以处理UNIX/DOS空格的编辑器以及合适的jar创建工具（例如JDK附带的jar工具）来满足所有MANIFEST的要求。

Bnd

Bnd 代表BuNDle工具，是由Peter Kriens（OSGi技术主管）创建的一个不错的实用程序，它“帮助……创建和诊断OSGi R4 bundle”。Bnd解析java类以了解可用的和导入的包，以便它可以创建等效的OSGi条目。Bnd提供了一系列指令和选项，可以自定义生成的工件。bnd.jar本身的好处是可以从命令行运行，通过专用的任务通过Ant运行，或作为插件集成到Eclipse中。

Bnd可以从类路径或Eclipse项目中可用的类创建jar文件，也可以通过添加必要的OSGi工件来将现有的jar文件转换为osgi格式。此外，它可以打印和验证给定jar文件的OSGi信息，使其成为一个功能强大且易于使用的工具。

第一次使用的用户可以使用Bnd查看将添加到普通jar文件的OSGi清单。让我们选择一个普通的jar文件，例如c3p0（这是一个优秀的连接池库），并发出打印命令

```code java -jar bnd.jar print c3p0-0.9.1.2.jar ```

输出相当大，包含几个部分

1. 通用清单信息

   [MANIFEST c3p0-0.9.1.2.jar]
   Ant…

Spring Batch 1.0.0.m4 今天可以通过 s3 Milestone 仓库获得（在 http://s3browse.com/explore/maven.springframework.org/milestone/org/springframework/batch 浏览）。请查看 Spring Batch 下载页面了解更多信息 (http://static.springframework.org/spring-batch)。

我们重新调整了发布计划，加入了一个额外的里程碑版本，Ben 和 Lucas 专注于此，因此 1.0.0.m5 将在未来 10-14 天内发布。然后我们只有时间发布 rc1，如果需要，可以考虑 rc2，然后在预计的 3 月 20 日最终发布之前。

我们一直在努力工作，准备 Spring Batch 迎接 Spring 产品组合 2.5 发布列车，我认为现在是更新大家正在发生的事情的好时机。在这篇文章中，我将对领域建模进行一些扩展，以及我们提高一些核心领域对象配置文件的决定，并增加它们的职责。我还将简要介绍即将发布的几个版本（直到 1.0），以便人们有机会发表评论。

为此道歉：内部进行了一些相当重大的更改……

我的上一篇博客展示了 Spring 如何超越 EJB。BZ Media 及其他机构的研究表明，Apache Tomcat 是领先的开源应用服务器，市场渗透率为 64%。Spring 和 Tomcat 的主导地位是众所周知的。人们可能不太了解的是，数千家组织正在将 Spring 部署在 Tomcat 上作为其中间件基础设施。这些组织希望有一家公司能够为他们提供取得成功的产品和服务。

今天，我们宣布收购Covalent Technologies。Covalent 不仅带来了 Apache 的领导地位，而且我们合并后的公司现在在 Apache Tomcat 和 HTTP 方面都具有显著的领导地位。两周前，Sun斥资 10 亿美元收购了 LAMP 中的“M”。现在 Covalent 杰出的 Apache 专业知识和服务已成为 SpringSource 的一部分，我们在“A”方面也占据了强大的领导地位。我们一直致力于技术领导地位，因此我们对与 Covalent 共同努力能够取得的成就感到非常兴奋。在过去的几年里，Covalent 通过其对 Apache 项目（包括 Tomcat 和 Apache HTTP）的支持赢得了良好的市场声誉。其数百名支持客户包括超过一半的财富 500 强公司，以及辉瑞、强生、英国电信 (BT)、美国宇航局、英特尔、苏格兰皇家银行和贝尔斯登等家喻户晓的名字。我们的公告……

Spring 2.5 背后的一个核心主题是基于注释的全面配置。我们一直在讨论和撰写关于@Autowired、关于 Spring MVC 的@RequestMapping以及关于对使用 JUnit4 或 TestNG 编写的带注释的测试的新支持的博客。@Autowired无疑是 Spring 2.5 注释的核心，可用于服务组件、Web 组件、单元测试——甚至在使用 Spring 的@Configurable进行 AspectJ 织入时用于领域对象。Spring MVC 的@RequestMapping同样灵活，支持许多变体的处理程序方法签名。

今天我……

好吧，这花费的时间比我们最初预期的要长得多，但我非常高兴地宣布，Spring 动态模块项目今天达到了 1.0 里程碑。当我于 2006 年 9 月首次发表关于此主题的文章（“Spring OSGi 支持正在发展势头”）时，最初的规范只是 Spring 框架问题的一个附件，与更广泛的 OSGi 社区的联系才刚刚开始形成。

快进十八个月，Spring 动态模块已成为 Spring 产品组合中的一个成熟项目，拥有来自 SpringSource、BEA 和 Oracle 的提交者。BEA 和 Oracle 都在使用 Spring 动态模块构建他们自己的基于 OSGi 的产品（例如，参见“WebLogic 事件服务器 - 我们为什么使用 Spring”），Spring 动态模块讨论组拥有近 1000 名成员。OSGi 联盟本身已经组建了一个企业专家组……

我很高兴地报告（与Adrian一起），在经历了 3 个里程碑版本和 2 个候选版本之后，Spring 动态模块（以前称为 Spring OSGi）1.0 已发布。

自从我之前的帖子（关于 1.0 M1）以来，许多功能得到了改进或添加；我将在以后的文章中详细讨论它们（还有解释库的详细文档），所以我只列举几个

- 一致性

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

- 高度非侵入性

使用 Spring DM 的推荐方法是**不要**在代码中使用其类，也不要在 bundle 清单中包含任何导入。如果您没有在代码中使用 Spring，而只是用于应用程序配置，则同样适用。Spring DM 为您创建应用程序上下文，因此您无需依赖 Spring 或 Spring DM。并且不要担心自定义命名空间或 XML 模式——我们已经涵盖了它们。

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

这是 Spring DM 最重要的功能之一——能够像处理普通 bean 一样与 OSGi 服务交互。您可以发布和使用 OSGi 服务而无需编写任何代码；我们将为您处理动态——并且您可以完全控制（以后会详细介绍）。

- 更智能的集成测试框架

由于我们在内部广泛使用 Spring-DM 集成测试，因此我们改进了默认值、Maven 集成，并使自动清单生成比以前更快、更智能。例如，框架会自动确定测试 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个Bundle，除非您的模块实际启动，否则不会占用CPU时间。

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

关于工具，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集成测试”