在他的最近的博文中,Glyn 介绍了 OSGi 的“uses”指令。在这篇博文中,我想更深入地探讨 uses 约束冲突的原因,并提供一些诊断应用程序中 uses 问题的小贴士。
对于大多数示例,我将使用原始的 Equinox 而不是 dm Server。原因是 uses 约束并非特定于 dm Server,而是与所有 OSGi 用户相关。在这篇博文的末尾,我将演示 dm Server 内置的一些智能约束失败诊断功能。
依赖约束不匹配
uses 冲突最常见的原因是一个或多个依赖约束不匹配。以以下三个 Manifest 为例
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 bundle 和两个 eclipselink bundle。显然,这些不是真实的 bundle。spring bundle 导入了 eclipselink 包,范围是 [1.0, 2.0)。显然,只有 eclipselink_1 bundle 可以满足这个约束。现在,考虑来自两个不同应用程序的这些 Manifest
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。如果我将这些 bundle 安装到 Equinox 中,然后尝试启动 app bundle,控制台将显示类似以下内容
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 bundle 都已解析。app1 bundle 已经启动,但 app2 bundle 未启动。要找出原因,我们可以使用 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 bundle 无法解析,因为它导入的 spring.orm.hibernate 存在包 uses 冲突。这意味着 app2 中对 spring.orm.hibernate 的导入无法满足,因为它的其他导入与 *可能* 提供 spring.orm.hibernate 的 bundle(在本例中是 spring bundle)上的 uses 约束发生冲突。
诊断此问题的第一步是找出 spring.orm.hibernate bundle 的可能供应商。从我们的用例中可知,唯一可能的供应商是 spring bundle,但如果您不知道供应商,可以使用 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 包由 bundle 2 导出。有了这些信息,我们可以找出在 bundle 2 的 uses 指令中列出的 spring.orm.hibernate 包包含哪些包
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 bundle 需要范围为 [1.0, 2.0) 的 eclipselink,而 app2 需要范围为 [2.0, 2.0] 的 eclipselink - 这两个范围互斥,这意味着 app2 *不能* 与 spring bundle 连接到相同版本的 eclipselink。
在 uses 列表很长的情况下,您可以通过找出哪些列出的包有多个供应商来缩小可能的冲突范围。必须存在多个供应商才能出现 uses 约束冲突。
版本不匹配并非依赖约束不匹配的唯一原因。约束可能由于属性以及版本而无法匹配。
安装顺序问题
如果我们回到前面的例子,并将 spring bundle 的 manifest 修改为可以接受 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"
安装 bundle 并启动 app bundle 表明这一改变产生了很大的不同
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
现在两个 app bundle 都可以启动了。不幸的是,还有一个更微妙的问题等待着我们。取决于安装顺序,这组 bundle 仍然可能无法一起运行。为了说明这一点,让我们将 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
应用程序 2 Bundle 不会启动。来自 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 约束又出现了。按照上一节中确定的诊断步骤在这里不会有帮助,因为没有依赖约束不匹配 - 我们知道这一点,因为第一次这些 Bundle 都能正常解析。
这里的问题是解析顺序。Bundle 分成两个不同的块安装和解析。第一个块包括 spring、eclipselink_1 和 app1,第二个块包括 eclipselink_2 和 app2。当第一个块解析时(作为启动 app1 Bundle 的结果),spring Bundle 将其导入的 eclipselink 包连接到 eclipselink_1 Bundle。这可以通过控制台进行确认
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 bundle。当第二个块安装后,app2 bundle 无法解析,因为它需要版本 2.0.0 的 eclipselink,而 spring 已连接到版本 1.0.0 的 eclipselink。当所有 bundle 都作为一个块安装和解析时,OSGi 解析器会尝试满足 *所有* 约束,包括确保可以满足 spring.orm.hibernate 上的 uses 约束。
要解决这个问题,我们不需要更改 Bundle。相反,我们可以将 Bundle 作为一块重新安装,或者我们可以触发对 spring Bundle 的刷新 - 实际上是要求 OSGi 重新运行解析过程。既然 eclipselink_2 Bundle 已安装,我们可以期望得到不同的结果
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 bundle 得以解析。spring 中 eclipselink 包的连接已更改为由 eclipselink_2 bundle 导出的版本 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 自动诊断。