亲爱的 Spring 社区：

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

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

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

在接触 OSGi 时，首先要掌握的概念之一就是“捆绑包”（bundle）。在这篇文章中，我想更详细地探讨一下捆绑包究竟是什么，以及一个普通的 jar 文件如何能被转换成一个 OSGi 捆绑包。那么，废话不多说，

什么是捆绑包？

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

捆绑包是一个 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 或 JDK 1.4 的 backport-util-concurrent 库）。

在 OSGi 术语中，根据包的可用性来依赖包相当于一个*可选*的 Package-Import。你在前面的示例中已经见过这样的包

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

版本*的含义*完全由捆绑包提供者决定，但是，建议使用流行的编号方案，例如 Apache APR 项目的方案，其中

• <major> - 表示不保证兼容性的重大更新
• <minor> - 表示保留与旧 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 元数据

现在我们已经了解了捆绑包是什么，让我们看看我们可以使用哪些工具来将现有的 jar 文件 osgi 化。

手动

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

但是，如果有人确实想/需要直接处理清单，那么应该使用一个可以处理 UNIX/DOS 空格的编辑器，并配合一个合适的 jar 创建实用程序（例如 JDK 自带的 jar 工具）来处理所有 MANIFEST 要求。

Bnd

Bnd 代表 BuNDle tool，是 Peter Kriens（OSGi 技术官）创建的一个好用的工具，它“帮助 [...] 创建和诊断 OSGi R4 捆绑包”。Bnd 解析 Java 类以了解可用的和导入的包，从而可以创建相应的 OSGi 条目。Bnd 提供一系列指令和选项，可以自定义生成的工件。bnd.jar 本身的好处在于它可以从 命令行运行，通过 Ant 的专用 任务运行，或者作为 插件集成到 Eclipse 中。

Bnd 可以从类路径或 Eclipse 项目中的类创建 jar，或者通过添加所需的 OSGi 工件来 osgi 化现有的 jar。此外，它可以打印和验证给定 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 里程碑存储库获得（请在 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 Portfolio 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”（Apache）方面取得了强大的领导地位。我们一直致力于技术领先，因此我们对与 Covalent 共同取得的成就感到非常兴奋。过去几年，Covalent 以其对 Tomcat 和 Apache HTTP 等 Apache 项目的支持，在市场上赢得了极佳的声誉。其数百家支持客户包括超过一半的 Fortune 500 公司，以及辉瑞（Pfizer）、强生（Johnson & Johnson）、英国电信（BT）、NASA、英特尔（Intel）、苏格兰皇家银行（Royal Bank of Scotland）和贝尔斯登（Bear Stearns）等知名企业。我们的公告……

Spring 2.5 的核心主题之一是全面的基于注解的配置。我们已经讨论和撰写了很多关于 **@Autowired**、Spring MVC 的 **@RequestMapping** 以及对使用 JUnit4 或 TestNG 编写的注解测试的新支持。**@Autowired** 毫无疑问是 Spring 2.5 注解的核心，可用于服务组件、Web 组件、单元测试——甚至在使用 Spring 的 **@Configurable** 和 AspectJ weaving 时也可以用于领域对象。Spring MVC 的 **@RequestMapping** 也同样灵活，支持多种 handler 方法签名变体。

今天我…

好吧，这比我们最初预期的要花费更长的时间，但我很高兴地说，Spring Dynamic Modules 项目今天达到了其 1.0 版本里程碑。当我于 2006 年 9 月首次发布有关此主题的文章（“Spring OSGi 支持势头强劲”）时，最初的规范只是 Spring Framework 的一个问题附件，并且与更广泛的 OSGi 社区的联系才刚刚开始形成。

快进十八个月，Spring Dynamic Modules 已成为 Spring 产品组合中的一个成熟项目，拥有来自 SpringSource、BEA 和 Oracle 的提交者。BEA 和 Oracle 都在使用 Spring Dynamic Modules 来构建自己的基于 OSGi 的产品（例如，请参阅“WebLogic Event Server - 我们为什么使用 Spring”），并且 Spring Dynamic Modules 讨论组已有近 1000 名成员。OSGi 联盟本身已成立了一个 企业专家组……

我很高兴（与 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 集成测试”