¿Por qué se violan las restricciones de uso cuando ambas cadenas terminan en el mismo paquete?

151

Tengo cuatro paquetes, cada uno con solo un manifiesto. Los paquetes son

appque importa com.example.foo.fragmentycom.example.bar
foo que exporta com.example.foo;uses:=com.example.foo.cfg
foo.fragmentque es un fragmento adjunto a las fooexportaciones com.example.foo.fragmentycom.example.foo.fragment.cfg;uses:=com.example.foo.fragment
barque exporta com.example.bare importacom.example.foo

Gráfico de dependencia de nivel de paquete :

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

Cuando instalo estos paquetes de una vez en JBoss AS 7.2, funcionan bien. Pero si instalo el apppaquete después de los demás, ya sea por primera vez o después de comenzar con éxito y luego desinstalarlo, se produce la siguiente violación de restricción de uso:

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

Los manifiestos completos son:

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

No he podido reproducir el error anterior en Apache Felix 4.2.1 independiente.

¿Cuál es la causa de este comportamiento? Si elimino la Fragment-Host: com.example.foofila del foo.fragmentmanifiesto, puedo reinstalar appmuy bien sin errores. ¿Es esto un error en JBoss AS 7.2?

osgi jboss7.x apache-felix

— Emil Lundberg
fuente

Estoy de acuerdo en que esto es bastante raro. Estoy tentado a llamar a esto un error en la implementación del marco JBoss AS, en cuyo caso debe informarse en la lista de correo de JBoss y / o en el rastreador de problemas.

— Neil Bartlett

Después de analizarlo un poco, noté que esto solo ocurre si mi aplicación no se implementa cuando se inicia JBoss. Quizás haya, después de todo, otro paquete de exportación org.hibernate.annotations, y la plataforma OSGi lo resuelve como la dependencia del paquete Spring ORM si la plataforma OSGi se inicia sin mi aplicación. Luego implemento mi aplicación y OSGi no puede resolverla porque no es compatible con el org.hibernate.annotationspaquete resuelto en el paquete Spring ORM. ¿Eso suena factible?

— Emil Lundberg

Ahora también comencé una discusión en la comunidad JBoss: community.jboss.org/thread/229824

— Emil Lundberg

@NeilBartlett Acabo de encontrar la respuesta a la pregunta 2: la exportación del paquete org.hibernate.annotationses un fragmento con Fragment-Host: com.springsource.org.hibernate.

— Emil Lundberg

Esto parece un error. Se supone que los paquetes de fragmentos deben actuar como si fueran parte de su paquete de host. Parece que en algunos casos JBoss está tratando el fragmento como un paquete separado cuando realiza la comprobación de consistencia de classpath.

— jgibson

No tiene que importar foo.fragment en la aplicación, su dependencia se resolverá desde foo. así que simplemente elimine esa dependencia y vuelva a implementarla. Este problema se debe a la dependencia cíclica.

— usuario3555572
fuente

Esto no es una dependencia cíclica . Sería cíclico si foo.fragment dependiera de la aplicación. Sin embargo, la aplicación depende de foo.fragment, por lo que no hay ciclo. Sin embargo, la dependencia explícita de la aplicación a foo.fragment puede ser innecesaria, eso es cierto.

— vog