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 自动诊断。