Por que as restrições de uso são violadas quando ambas as cadeias terminam no mesmo pacote?

151

Eu tenho quatro pacotes, cada um contendo apenas um manifesto. Os pacotes são

appquais importações com.example.foo.fragmentecom.example.bar
foo quais exporta com.example.foo;uses:=com.example.foo.cfg
foo.fragmentque é um fragmento ligado fooàquele que exporta com.example.foo.fragmentecom.example.foo.fragment.cfg;uses:=com.example.foo.fragment
barquais exportações com.example.bare importaçõescom.example.foo

Gráfico de dependência em nível de pacote configurável :

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

Quando instalo esses pacotes de uma vez no JBoss AS 7.2, eles funcionam bem. Mas se eu instalar o apppacote configurável após os outros, pela primeira vez ou após iniciar e desinstalar com êxito, ocorrerá a seguinte violação de restrição:

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

Os manifestos completos são:

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

Não consegui reproduzir o erro acima no Apache Felix 4.2.1 independente.

Qual é a causa desse comportamento? Se eu excluir a Fragment-Host: com.example.foolinha do foo.fragmentmanifesto, posso reinstalar appsem problemas. Isso é um bug no JBoss AS 7.2?

osgi jboss7.x apache-felix

— Emil Lundberg
fonte

Eu concordo que isso é bem estranho. Fico tentado a chamar isso de bug na implementação da estrutura do JBoss AS; nesse caso, ele deve ser relatado na lista de discussão do JBoss e / ou no rastreador de problemas.

— Neil Bartlett

Depois de mexer um pouco com ele, notei que isso só ocorre se meu aplicativo não for implantado quando o JBoss for inicializado. Talvez exista, afinal, outro pacote de exportação org.hibernate.annotationse a plataforma OSGi resolva isso como a dependência do pacote ORM Spring se a plataforma OSGi iniciar sem o meu aplicativo. Em seguida, implanto meu aplicativo e o OSGi falha ao resolvê-lo porque não é compatível com o org.hibernate.annotationspacote resolvido para o pacote Spring ORM. Isso parece viável?

— Emil Lundberg

Tenho agora também começou uma discussão na comunidade JBoss: community.jboss.org/thread/229824

— Emil Lundberg

@ NeilBartlett Acabei de descobrir a resposta para a pergunta 2: a exportação de pacotes org.hibernate.annotationsé um fragmento Fragment-Host: com.springsource.org.hibernate.

— Emil Lundberg

Isso parece um bug. Os pacotes de fragmentos devem agir como se fossem parte do pacote de host. Parece que em alguns casos o JBoss está tratando o fragmento como um pacote separado ao executar a verificação de consistência do caminho de classe.

— Jgibson

Você não precisa importar foo.fragment no aplicativo, sua dependência será resolvida a partir de foo. então basta remover essa dependência e reimplantá-la. Esse problema ocorre devido à dependência cíclica.

— user3555572
fonte

Esta não é uma dependência cíclica . Seria cíclico se foo.fragment dependesse do aplicativo. No entanto, o aplicativo depende do foo.fragment, portanto não há ciclo. No entanto, a dependência explícita do aplicativo para o foo.fragment pode não ser necessária, isso é verdade.

— Vog