두 체인이 동일한 번들로 끝날 때 사용 제한 조건을 위반하는 이유는 무엇입니까?


151

각 매니페스트 만 포함 된 4 개의 번들이 있습니다. 번들은

  • 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.foo행을 삭제하면 오류없이 잘 foo.fragment다시 설치할 수 app있습니다. JBoss AS 7.2의 버그입니까?


1
나는 이것이 매우 이상하다는 것에 동의합니다. JBoss AS 프레임 워크 구현에서이 버그를 버그라고 부르고 싶습니다.이 경우 JBoss 메일 링리스트 및 / 또는 이슈 트래커에보고해야합니다.
Neil Bartlett

약간만 놀아 본 후 JBoss가 시작될 때 응용 프로그램이 배포되지 않은 경우에만 발생합니다. 어쩌면 다른 번들 내보내기가 org.hibernate.annotations있을 수 있으며 OSGi 플랫폼은 OSGi 플랫폼이 내 응용 프로그램없이 시작되면 Spring ORM 번들의 종속성으로 해결합니다. 그런 다음 애플리케이션을 배치 org.hibernate.annotations하면 Spring ORM 번들로 분석 된 번들 과 호환되지 않기 때문에 OSGi가이를 해결하지 못합니다 . 그게 가능합니까?
Emil Lundberg 2016 년

4
지금 또한 제이보스 커뮤니티 토론 시작했습니다 : community.jboss.org/thread/229824을
에밀 룬드 버그에게

@NeilBartlett 난 그냥 질문 2에 대한 답을 알아 낸 : 수출 번들이 org.hibernate.annotations있는 조각이다 Fragment-Host: com.springsource.org.hibernate.
Emil Lundberg

1
이것은 버그처럼 보입니다. 조각 번들은 마치 호스트 번들의 일부인 것처럼 작동해야합니다. 일부 경우 JBoss가 클래스 경로 일관성 검사를 수행 할 때 조각을 별도의 번들로 취급하는 것처럼 보입니다.
jgibson

답변:


1

앱에서 foo.fragment를 가져올 필요가 없으며 foo에서 종속성이 해결됩니다. 그 의존성을 제거하고 다시 배포하십시오. 이 문제는 주기적 종속성 때문에 발생합니다.


3
이것은 순환 종속성아닙니다 . foo.fragment가 앱에 의존하면 주기적입니다. 그러나 응용 프로그램은 foo.fragment에 의존하므로주기가 없습니다. 그러나 앱에서 foo.fragment 로의 명시 적 종속성이 필요하지 않을 수 있습니다.
vog jan
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.