Glyn 在他最近的博客文章中介绍了 OSGi “uses” 指令。在这篇博客中，我想更深入地探讨 uses 约束违规的原因，并提供一些诊断应用程序中 uses 问题的技巧。

对于大多数示例，我将使用原始的 Equinox 而不是 dm Server。原因在于 uses 约束并非 dm Server 特有，而是与所有 OSGi 用户相关。在这篇博客的最后，我将演示 dm Server 中内置的一些智能约束失败诊断。

依赖约束不匹配

uses 违规最常见的原因是一个或多个依赖约束不匹配。举个例子，考虑下面的三个清单

Manifest-Version: 1.0
Bundle-Name: Spring Bundle
Bundle-ManifestVersion: 2
Bundle-SymbolicName: spring
Bundle-Version: 2.5.5
Export-Package: spring.orm.hibernate;version="2.5.5";uses:="eclipselink"
Import-Package: eclipselink;version="[1.0, 2.0)"

Manifest-Version: 1.0
Bundle-Name: EclipseLink 1 Bundle
Bundle-ManifestVersion: 2
Bundle-SymbolicName: eclipselink
Bundle-Version: 1
Export-Package: eclipselink;version="1.0.0"

Manifest-Version: 1.0
Bundle-Name: EclipseLink 2 Bundle
Bundle-ManifestVersion: 2
Bundle-SymbolicName: eclipselink
Bundle-Version: 2
Export-Package: eclipselink;version="2.0.0"

这里您可以看到一个 spring 捆绑包和两个 eclipselink 捆绑包。显然，这些不是真正的捆绑包。spring 捆绑包导入了范围为 [1.0, 2.0) 的 eclipselink 包。显然，只有 eclipselink_1 捆绑包可以满足此约束。现在，考虑来自两个不同应用程序的这些清单

Manifest-Version: 1.0
Bundle-Name: App1 Bundle
Bundle-ManifestVersion: 2
Bundle-SymbolicName: app1
Bundle-Version: 1.0.0
Import-Package: spring.orm.hibernate,eclipselink;version="[1.0, 1.0]"

Manifest-Version: 1.0
Bundle-Name: App2 Bundle
Bundle-ManifestVersion: 2
Bundle-SymbolicName: app2
Bundle-Version: 1.0.0
Import-Package: spring.orm.hibernate,eclipselink;version="[2.0, 2.0]"

这里我们可以看到 app1 导入了范围 [1.0, 1.0] 的 eclipselink，app2 导入了范围 [2.0, 2.0] 的 eclipselink。如果我将这些捆绑包安装到 Equinox 中，然后尝试启动应用程序捆绑包，控制台会显示类似以下内容

id      State       Bundle
0       ACTIVE      org.eclipse.osgi_3.4.0.v20080605-1900
2       RESOLVED    spring_2.5.5
3       RESOLVED    eclipselink_1.0.0
4       RESOLVED    eclipselink_2.0.0
5       ACTIVE      app1_1.0.0
6       INSTALLED   app2_1.0.0

这里我们可以看到 spring 和 eclipselink 捆绑包都已解析。app1 捆绑包已启动，但 app2 捆绑包无法启动。要找出原因，我们可以使用 diag 命令

osgi> diag app2
file:/Users/robharrop/dev/resdiag/uses/app2/bin [6]
  Package uses conflict: Import-Package: spring.orm.hibernate; version="0.0.0"

这里我们可以看到 app2 捆绑包无法解析，因为它导入的 spring.orm.hibernate 存在包 uses 冲突。这意味着 app2 中对 spring.orm.hibernate 的导入无法满足，因为它的其他导入之一与可能提供 spring.orm.hibernate 的捆绑包（在本例中是 spring 捆绑包）上的 uses 约束发生冲突。

诊断此问题的第一步是找出 spring.orm.hibernate 捆绑包的可能提供者。从我们的用例中我们知道唯一可能的提供者是 spring 捆绑包，但如果您不知道提供者，可以使用 packages 命令找到它们

osgi> packages spring.orm.hibernate
spring.orm.hibernate; version="2.5.5"<file:/Users/robharrop/dev/resdiag/uses/spring/bin [2]>
  file:/Users/robharrop/dev/resdiag/uses/app1/bin [5] imports

这表明 spring.orm.hibernate 包由捆绑包 2 导出。有了这些知识，我们可以找出捆绑包 2 中 spring.orm.hibernate 包的 uses 指令中列出的包

osgi> headers 2
Bundle headers:
 Bundle-ManifestVersion = 2
 Bundle-Name = Spring Bundle
 Bundle-SymbolicName = spring
 Bundle-Version = 2.5.5
 Export-Package = spring.orm.hibernate;version="2.5.5";uses:="eclipselink"
 Import-Package = eclipselink;version="[1.0, 2.0)"
 Manifest-Version = 1.0

这里我们可以看到 uses 中唯一的包是 eclipselink 包，所以它一定是罪魁祸首。确实，我们可以看到 Spring 捆绑包需要范围为 [1.0, 2.0) 的 eclipselink，而 app2 需要范围为 [2.0, 2.0] 的 eclipselink - 这两个范围是互斥的，这意味着 app2 无法与 spring 捆绑包连接到相同版本的 eclipselink。

在 uses 列表很长的情况下，您可以通过找出列出的哪些包具有多个供应商来缩小可能的违规范围。必须始终有多个供应商才能看到 uses 约束违规。

版本不匹配并非依赖约束不匹配的唯一原因。约束可能由于属性以及版本而不匹配。

安装顺序问题

如果我们回到之前的示例，并更改 spring 捆绑包的清单，使其能够接受版本 2.0 的 eclipselink 包，并放宽 app1 的范围，使其能够接受 1.0 以上的任何版本，我们应该能够解决这个问题

Manifest-Version: 1.0
Bundle-Name: Spring Bundle
Bundle-ManifestVersion: 2
Bundle-SymbolicName: spring
Bundle-Version: 2.5.5
Export-Package: spring.orm.hibernate;version="2.5.5";uses:="eclipselink"
Import-Package: eclipselink;version="[1.0, 2.0]"

Manifest-Version: 1.0
Bundle-Name: App1 Bundle
Bundle-ManifestVersion: 2
Bundle-SymbolicName: app1
Bundle-Version: 1.0.0
Import-Package: spring.orm.hibernate,eclipselink;version="1.0"

安装捆绑包并启动应用程序捆绑包表明这种改变产生了很大的不同

id      State       Bundle
0       ACTIVE      org.eclipse.osgi_3.4.0.v20080605-1900
1       RESOLVED    spring_2.5.5
2       RESOLVED    eclipselink_1.0.0
3       RESOLVED    eclipselink_2.0.0
4       ACTIVE      app1_1.0.0
5       ACTIVE      app2_1.0.0

现在两个应用程序捆绑包都可以启动。不幸的是，还有一个更微妙的问题等待着我们。根据安装顺序，这组捆绑包可能仍然无法一起运行。为了说明这一点，让我们将 spring、eclipselink_1 和 app1 作为一次事务安装，并启动 app1

id      State       Bundle
0       ACTIVE      org.eclipse.osgi_3.4.0.v20080605-1900
1       RESOLVED    spring_2.5.5
2       RESOLVED    eclipselink_1.0.0
3       ACTIVE      app1_1.0.0

现在，让我们安装 eclipselink_2 和 app2

id      State       Bundle
0       ACTIVE      org.eclipse.osgi_3.4.0.v20080605-1900
1       RESOLVED    spring_2.5.5
2       RESOLVED    eclipselink_1.0.0
3       ACTIVE      app1_1.0.0
4       RESOLVED    eclipselink_2.0.0
5       INSTALLED   app2_1.0.0

app2 捆绑包无法启动。diag 的输出告诉我们原因

osgi> diag app2
file:/Users/robharrop/dev/resdiag/uses/app2/bin [5]
  Package uses conflict: Import-Package: spring.orm.hibernate; version="0.0.0"

uses 约束又回来了。运行上一节中确定的诊断步骤将无济于事，因为没有依赖约束不匹配——我们知道这一点，因为第一次这些捆绑包解析得很好。

这里的问题是解析顺序。捆绑包分两个不同的块安装和解析。第一个块包括 spring、eclipselink_1 和 app1，第二个块包括 eclipselink_2 和 app2。当第一个块被解析（由于启动 app1 捆绑包）时，spring 捆绑包会将其对 eclipselink 包的导入连接到 eclipselink_1 捆绑包。这可以通过控制台确认

osgi> bundle app1
file:/Users/robharrop/dev/resdiag/uses/app1/bin [3]
  Id=3, Status=ACTIVE      Data Root=/opt/springsource-dm-server-1.0.0.RELEASE/lib/configuration/org.eclipse.osgi/bundles/3/data
  No registered services.
  No services in use.
  No exported packages
  Imported packages
    spring.orm.hibernate; version="2.5.5"<file:/Users/robharrop/dev/resdiag/uses/spring/bin [1]>
    eclipselink; version="1.0.0"<file:/Users/robharrop/dev/resdiag/uses/eclipselink1/bin [2]>
  No fragment bundles
  Named class space
    app1; bundle-version="1.0.0"[provided]
  No required bundles

请注意，导入的包部分显示 eclipselink 版本 1.0.0 是从 eclipselink_1 捆绑包导入的。当第二个块安装时，app2 捆绑包无法解析，因为它需要版本 2.0.0 的 eclipselink，但 spring 已经连接到版本 1.0.0 的 eclipselink。当所有捆绑包作为一个块安装和解析时，OSGi 解析器将尝试满足所有约束，包括确保 spring.orm.hibernate 上的 uses 约束能够满足。

要解决此问题，我们无需更改我们的捆绑包。相反，我们可以将捆绑包重新安装到一个块中，或者我们可以触发对 spring 捆绑包的刷新——实际上是要求 OSGi 重新运行解析过程。现在 eclipselink_2 捆绑包已安装，我们可以预期会有不同的结果

osgi> refresh spring

osgi> ss

Framework is launched.

id      State       Bundle
0       ACTIVE      org.eclipse.osgi_3.4.0.v20080605-1900
1       RESOLVED    spring_2.5.5
2       RESOLVED    eclipselink_1.0.0
3       ACTIVE      app1_1.0.0
4       RESOLVED    eclipselink_2.0.0
5       ACTIVE      app2_1.0.0

osgi> bundle spring
file:/Users/robharrop/dev/resdiag/uses/spring/bin [1]
  Id=1, Status=RESOLVED    Data Root=/opt/springsource-dm-server-1.0.0.RELEASE/lib/configuration/org.eclipse.osgi/bundles/1/data
  No registered services.
  No services in use.
  Exported packages
    spring.orm.hibernate; version="2.5.5"[exported]
  Imported packages
    eclipselink; version="2.0.0"<file:/Users/robharrop/dev/resdiag/uses/eclipselink2/bin [4]>
  No fragment bundles
  Named class space
    spring; bundle-version="2.5.5"[provided]
  No required bundles

请注意，刷新 spring 导致 app2 捆绑包解析。spring 中 eclipselink 包的连接已更改，由 eclipselink_2 捆绑包中版本 2.0.0 的导出满足。

dm Server 中的 Uses 约束

当您在 dm Server 中遇到 uses 约束违规时，我们已经尝试为您执行一些分析步骤，特别是识别可能不匹配的依赖约束

Could not satisfy constraints for bundle 'app2' at version '1.0.0'.
 Cannot resolve: app2
  Resolver report:
    Bundle: app2_1.0.0 - Uses Conflict: Import-Package: spring.orm.hibernate; version="0.0.0"
      Possible Supplier: spring_2.5.5 - Export-Package: spring.orm.hibernate; version="2.5.5"
        Possible Conflicts: eclipselink

Uses 约束在企业库中很常见，手动诊断失败可能是一个真正的噩梦。特别是，当导出的包在其 uses 子句中列出 10 个或更多包时，确定可能的冲突可能非常耗时。因此，自动化诊断是必须的，我希望不断改进 dm Server 中的诊断代码，以便处理常见错误变得微不足道。

在下一个版本中，我们计划将诊断工具直接内置到我们的 dm Server Eclipse 工具中，这样大部分问题将由 dm Server 自动诊断。

我很高兴地宣布，这是自SpringSource收购G2One以来，Grails的首个发布。Grails 1.0.4包含一系列改进以及底层Grails关键库的升级，可从Grails下载页面下载。更具体地说，Grails 1.0.4集成了大约一周前发布的最新的Spring 2.5.6版本。

除了这些改进之外，本次发布还有几个有趣的新特性。首先是增加了一个更好地支持GORM中Hibernate用户类型定义的映射的特性。您现在可以映射自定义用户类型……

我很高兴地宣布，SpringSource已收购G2One，该公司是Grails和Groovy的幕后推手。

为什么？

Grails与Spring和SpringSource技术非常契合。Grails建立在Spring之上。它提供了另一种采用Spring的方式，Spring是企业Java的事实标准组件模型。Spring（和Java）的所有强大功能都隐藏在每个基于Grails的应用程序的表面之下——这是Grails能够扩展到企业级应用的关键原因，也是对Spring强大和灵活性的验证。

与Spring一样，Grails是一项简化开发者生活并提高其生产力的技术。正如我们新的标语对抗Java复杂性的武器所反映的，简化一直是我们作为公司和技术人员的核心。

介绍

1. 使用 SpringSource Tool Suite 从头开始构建并以 WAR 文件形式将 GWT StockWatcher 示例应用程序部署到 dm Server 中。
2. 使用 “共享库” 方法部署：如何从 WAR 中移除 GWT 依赖项并将其作为 OSGi 捆绑包部署到 dm Server 中。
3. 使用 “共享服务” 方法部署：我们将单个 WAR 文件转换为 OSGi 服务，这些服务可以被其他应用程序共享并热插拔。

背景

这篇博客假设您已安装 SpringSource Tool Suite 1.1.1（我使用的是 Eclipse 3.4 版本）、  dm Server 1.0.0 和 GWT 1.5。它还假设您对 Java 编程有很好的理解，并且对 Javascript 和 Ajax 有基本的了解。

为了演示中使用的路径，我在/Users/bcorrie/gwt/workspace创建了一个新的 Eclipse 工作区。我已在下方包含了可以下载的压缩项目，其中包含一个我定义的GWT_ROOT_INSTALL变量。要使用我的项目，当您导入它们时，请导航到“Preferences”->“Java”->“Build Path”->“Classpath Variables”并定义您自己的GWT_ROOT_INSTALL…

不是11月4日的奥巴马/麦凯恩对决。正如您可能在SD Times上读到的那样，SpringSource已与SAP、爱立信、诺基亚、飞利浦和IBM一同当选Java SE/EE JCP执行委员会。我将是SpringSource的代表。

这并不是说JCP的规模能与总统竞选相提并论。但这对于SpringSource来说是一个重要的时刻，它反映了SpringSource团队在企业Java领域多年来的辛勤工作和领导力。更重要的是，我相信我们的当选将有助于我们使Java更加强大。

从第一本书到……

更新于 2008 年 10 月 28 日：添加了最新的示例链接和第三个示例链接

昨晚，我在费城 Spring 用户组发表了“SpringSource dm Server 简介”演讲。在这次演讲中，我创建了一个名为 GreenPages 的小型应用程序，展示了 dm Server 的所有主要方面。我向与会者承诺，我将在此处发布该应用程序和幻灯片。

在 dm Server GA 版发布后的几周里，许多人都在询问如何最好地开始使用 dm Server，所以我用这篇文章来收集所有相关信息……

在本文中，我们概述了Spring Batch 2.0的主要主题，并重点介绍了与1.x版本的变化。新版本的开发工作正在顺利进行，上周发布了M2版本，并且我们获得了大量关注，因此现在似乎是提供一些指针的好时机。

Spring Batch 2.0 主题

新版本的四个主要主题是

• Java 5和Spring 3.0
• 非顺序执行
• 可伸缩性
• 配置：注解和XML命名空间

Spring Batch 2.0.0.M2的项目物理布局没有任何变化（相同的旧下载，相同的Java包基本布局）。我们没有删除任何功能，但我们借此机会修改了几个API，并且有一些小的更改……

如果您为SpringSource dm Server或任何其他OSGi平台构建应用程序，您迟早会遇到“uses”指令。除非您清楚地理解该指令的目的，否则您将不知道何时编写它，并且当某个bundle由于“uses”冲突而无法解析时，您将只能猜测。本文应让您全面了解“uses”指令，何时使用它，以及如何调试“uses”冲突。

Bundle解析

OSGi的设计使得一旦bundle被“解析”，您通常不应该遇到由于类型……导致的类转换异常以及类似问题。

几周前，Filip Hanik 和我举办了“优化和调整 Apache Tomcat”系列网络研讨会的第二部分。您可以通过 SpringSource 网站的网络研讨会部分获取网络研讨会的录音和幻灯片副本。同一页面上还有所有以前的 SpringSource 网络研讨会的链接，以及 Covalent 网络研讨会存档。

我们无法在问答环节中回答所有问题，所以，正如承诺的那样，以下是剩余问题和我们的答案。

• 如何识别 Tomcat 应用程序中的内存泄漏？

  您几乎肯定需要使用分析器来识别内存泄漏的根本原因。最新的 Sun JDK 包含 jhat 和 jmap 等工具。还有许多其他分析器可用，包括免费和商业的。Filip 和我在调查 Tomcat 内存泄漏时使用 YourKit，因为 YourKit 为开源开发者提供免费许可证。

• 重新部署如何导致内存泄漏？

  这通常发生在 Tomcat 加载的类保留对 Web 应用程序加载的类的引用时。当 Web 应用程序停止时，Tomcat 类加载器继续保留对 Web 应用程序加载的类的引用。这个类保留对 Web 应用程序的类加载器的引用，而 Web 应用程序的类加载器又保留对其加载的所有类的引用。因此，Web 应用程序类加载器及其加载的所有类都不符合垃圾回收的条件。这会导致内存泄漏。典型的根本原因是 JDBC 驱动程序和日志框架。

• 更改 Tomcat 使用的 JVM 的最佳方法是什么？

  要使用的 JVM 通过 JAVA_HOME（完整 JDK）或 JRE_HOME（仅 JRE）环境变量设置。设置它的正确位置将取决于您的环境，特别是如果 Tomcat 配置为在系统启动时自动启动。如果您可以自由选择设置位置，则根据您的操作系统使用 setenv.bat 或 setenv.sh。

• 您推荐特定的 JVM 吗？

  不，我们不推荐。您选择的 JVM 供应商取决于您的操作系统。

• 我应该使用哪个连接器将 Apache httpd 连接到 Tomcat？

  我们推荐 mod_proxy_http，mod_jk 紧随其后。通常，mod_proxy_ajp 不如 mod_proxy_http 或 mod_jk 稳定。请注意，mod_jk2 已被弃用，不应再使用。

• 使用 SSL 时，maxKeepAliveRequests 的正确设置是什么？

  使用 SSL 时，应启用 HTTP keep alive，因为 SSL 握手对于每个请求来说都是一个相对昂贵的操作。

• 如果我们在 Solaris 上运行 Tomcat，您是否不建议使用本机 APR 连接器？

  是的，我们不建议。我们从客户那里收到的反馈是 APR 连接器在 Solaris 上不稳定。

• 我们之前尝试在 Solaris 上迁移到 mod_proxy_http，但遇到了几个错误。这些错误是否已解决？

  在不知道确切的错误或您使用的版本的情况下，很难发表评论。所有已知的 Apache httpd 问题和当前状态都可以在 ASF Bugzilla 数据库中找到。Tomcat 问题也可以在 Bugzilla 中找到。

• 对于默认的阻塞 IO HTTP 连接器，maxKeepAliveRequests 应该使用什么值？

  对于高并发环境，将其设置为 1。否则，将其设置为您页面上的平均对象数，介于 10 到 100 之间。

• 如何配置 JkOptions +DisableReuse？

  JkOptions +DisableReuse 应放置在您的 httpd.conf 文件中，与其他 mod_jk 设置一起。

• 何时最适合使用非阻塞 IO HTTP 连接器？

  当您需要支持高并发且保持活动状态，并且 APR 不可用时，例如，因为它在您的平台上不稳定。

• 如果我在 Apache Tomcat 前面使用 Apache httpd，性能会更好吗？

  这取决于。如果您将所有请求代理到 Tomcat，那么性能会略有下降。如果 httpd 处理一些请求（例如所有静态内容），那么您可能会看到一些好处。有许多基准测试试图证明一个连接器比另一个连接器更好。但是，这些基准测试都不太可能代表您的应用程序。唯一确定的方法是在您的环境中，使用真实的负载和使用模式进行测试。

• Tomcat 可以在没有 Web 服务器的情况下投入生产使用吗？

  是的。这是否能为您的环境提供最佳性能将取决于该环境和您的应用程序。与上一个问题一样，唯一确定的方法是在您的环境中，使用真实的负载和使用模式进行测试。

• 在 Tomcat 前面使用 Apache httpd 会增加安全性吗？

  您的安装安全性将取决于许多因素。使用或不使用 Apache httpd 不太可能显着改变您的安装安全性。其他因素，例如及时更新补丁和使用防火墙，通常对您的整体安全性水平影响更大。

• 哪个 Apache httpd MPM 提供最佳性能？

  一如既往，这将取决于您的环境，但 httpd 性能调优文档提供了一些有用的通用指南。

• SpringSource ERS 和 Apache Tomcat 之间的性能差异是什么？

  SpringSource ERS 不仅仅是 Apache Tomcat。从纯粹的 Tomcat 角度来看，性能不是差异化因素。ERS 的优势在于简单的安装、易于管理的升级和修补、对多个实例的支持以及所有组件的集成。

• 我的公司使用 Tomcat 和 XYZ 应用程序服务器。Tomcat 与 XYZ 应用程序服务器相比如何，以及合并是否有好处？

  会有很多差异，而且重要的差异会因组织而异。首先确定您希望从应用程序服务器中获得什么，然后将该列表与市场进行比较。合并是有好处的。更大的一致性意味着更简单的维护、更少的培训等等。但是，也有成本。您需要查看您的组织及其计划如何合并（仅新项目、下一次主要发布的所有项目、现在所有项目等）以比较成本与相关收益。

• 您有 Tomcat 和 XYZ 应用程序服务器的性能比较数据吗？

  该领域已发布各种报告。结果的有用性取决于测试与您的负载匹配的程度。一如既往，唯一确定的方法是在您的环境中，使用真实的负载和使用模式进行测试。

• 负载测试 Tomcat 服务器的好方法是什么？

  有多种工具可用于驱动负载，包括免费和商业的。免费工具包括 ab 和 JMeter。

• 为了高可用性和性能，Tomcat 可以配置为为同一个 Web 应用程序启动多个 JVM 吗？

  Tomcat 不提供此配置选项。当然，您可以创建多个 Tomcat 实例，在每个实例上安装您的应用程序，然后跨实例进行负载均衡。

• 有通用的 Tomcat 健康检查脚本吗？

  管理器状态页面可能是一个很好的起点。如果需要，您可以使用该 Servlet 的代码作为您自己更具体/更广泛检查的基础。如果您确实进行了增强，请考虑将您的增强贡献回 Apache Tomcat 社区。

• logging.properties 文件位于何处？

  默认位置是 $CATALINA_BASE/conf。