当两个链都在同一个包中结束时,为什么违反使用约束?


151

我有四个捆绑包,每个捆绑包仅包含一个清单。捆绑是

  • app哪个进口com.example.foo.fragmentcom.example.bar
  • foo 哪个出口 com.example.foo;uses:=com.example.foo.cfg
  • foo.fragment这是foo该出口的一部分com.example.foo.fragmentcom.example.foo.fragment.cfg;uses:=com.example.foo.fragment
  • bar哪些com.example.bar进出口com.example.foo

捆绑级别的依赖图

app -> bar
|       |
|       v
|      foo
|       |
v       v
foo.fragment

当我在JBoss AS 7.2中一次安装所有捆绑软件时,它们就可以正常工作。但是,如果我是其他app捆绑软件之后安装捆绑软件,无论是第一次安装还是成功启动然后将其卸载之后,都会发生以下违反约束的情况:

Caused by: org.osgi.service.resolver.ResolutionException: Uses constraint violation. Unable to resolve resource com.example.app [HostBundleRevision[com.example.app:0.0.
0]] because it is exposed to package 'com.example.foo.fragment' from resources com.example.foo [HostBundleRevision[com.example.foo:0.0.0]] and com.example.foo [HostBund
leRevision[com.example.foo:0.0.0]] via two dependency chains.

Chain 1:
  com.example.app [HostBundleRevision[com.example.app:0.0.0]]
    import: null
     |
    export: osgi.wiring.package=com.example.foo.fragment
  com.example.foo [HostBundleRevision[com.example.foo:0.0.0]]

Chain 2:
  com.example.app [HostBundleRevision[com.example.app:0.0.0]]
    import: null
     |
    export: osgi.wiring.package=com.example.bar; uses:=com.example.foo
  com.example.bar [HostBundleRevision[com.example.bar:0.0.0]]
    import: null
     |
    export: osgi.wiring.package=com.example.foo; uses:=com.example.foo.fragment
    export: osgi.wiring.package=com.example.foo.fragment
  com.example.foo [HostBundleRevision[com.example.foo:0.0.0]]
        at org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1142)
        at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:197)
        at org.jboss.osgi.resolver.felix.StatelessResolver.resolve(StatelessResolver.java:56)
        at org.jboss.osgi.framework.internal.ResolverImpl.resolveAndApply(ResolverImpl.java:137)
        at org.jboss.as.osgi.service.BundleLifecycleIntegration$BundleLifecycleImpl.activateDeferredPhase(BundleLifecycleIntegration.java:296)
        ... 31 more

完整清单包括:

app.jar/META-INF/MANIFEST.MF
----------------------------
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-SymbolicName: com.example.app
Import-Package: com.example.foo.fragment,com.example.bar
----------------------------
foo.jar/META-INF/MANIFEST.MF
----------------------------
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-SymbolicName: com.example.foo
Export-Package: com.example.foo;uses:="com.example.foo.cfg"
-------------------------------------
foo.fragment.jar/META-INF/MANIFEST.MF
-------------------------------------
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-SymbolicName: com.example.foo.fragment
Fragment-Host: com.example.foo
Export-Package: com.example.foo.fragment,com.example.foo.cfg;uses:="co
 m.example.foo.fragment"
----------------------------
bar.jar/META-INF/MANIFEST.MF
----------------------------
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-SymbolicName: com.example.bar
Export-Package: com.example.bar;uses:="com.example.foo"
Import-Package: com.example.foo

我无法在独立的Apache Felix 4.2.1中重现以上错误。

这种行为的原因是什么?如果我Fragment-Host: com.example.foofoo.fragment清单中删除该行,则可以重新安装app而不会出现错误。这是JBoss AS 7.2中的错误吗?


1
我同意这很奇怪。我很想将其称为JBoss AS框架实现中的错误,在这种情况下,应在JBoss邮件列表和/或问题跟踪器中报告该错误。
尼尔·巴特利特

经过一番摸索之后,我注意到只有在JBoss启动时未部署我的应用程序时才会发生这种情况。毕竟,也许还会有另一个bundle导出org.hibernate.annotations,并且如果OSGi平台在没有我的应用程序的情况下启动,则OSGi平台会将其解析为Spring ORM捆绑包的依赖项。然后,我部署了应用程序,但OSGi无法解决它,因为它与org.hibernate.annotations解析为Spring ORM包的包不兼容。听起来可行吗?
Emil Lundberg 2013年

4
我现在也开始在JBoss社区中进行讨论:community.jboss.org/thread/229824
Emil Lundberg 2013年

@NeilBartlett我刚刚想出了问题2的答案:捆绑包导出org.hibernate.annotations是带有的片段Fragment-Host: com.springsource.org.hibernate
埃米尔·隆德伯格

1
这看起来像个错误。片段束应该被当作主机束的一部分来工作。在某些情况下,JBoss在执行类路径一致性检查时会将片段视为一个单独的束。
jgibson

Answers:


1

您不必在应用程序中导入foo.fragment,您的依赖项将从foo解析。因此,只需删除该依赖项,然后重新部署它即可。此问题是由于循环依赖性。


3
不是周期性依赖关系。如果foo.fragment依赖于应用程序,则它将是循环的。但是,应用程序取决于foo.fragment,因此没有周期。但是,可能不需要从app到foo.fragment的显式依赖关系。
vog 2015年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.