Pourquoi les contraintes d'utilisation sont-elles violées lorsque les deux chaînes se terminent dans le même faisceau ?

Question

J'ai quatre liasses, chacune ne contenant qu'un manifeste. Les paquets sont

• app qui importe com.example.foo.fragment y com.example.bar
• foo qui exporte com.example.foo;uses:=com.example.foo.cfg
• foo.fragment qui est un fragment attaché à foo qui exporte com.example.foo.fragment y com.example.foo.fragment.cfg;uses:=com.example.foo.fragment
• bar qui exporte com.example.bar et les importations com.example.foo

Graphique de dépendance au niveau des paquets :

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

Lorsque j'installe ces bundles en une seule fois dans JBoss AS 7.2, ils fonctionnent parfaitement. Mais si j'installe le app paquet après les autres, soit pour la première fois, soit après avoir réussi à le démarrer puis à le désinstaller, la violation de la contrainte d'utilisation suivante se produit :

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

Les manifestes complets sont :

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

Je n'ai pas été en mesure de reproduire l'erreur ci-dessus dans Apache Felix 4.2.1 autonome.

Quelle est la cause de ce comportement ? Si je supprime le Fragment-Host: com.example.foo rangée de la foo.fragment manifeste, je peux réinstaller app sans erreur. S'agit-il d'un bogue dans JBoss AS 7.2 ?

Answer 1

Vous n'avez pas besoin d'importer foo.fragment dans l'application, votre dépendance sera résolue à partir de foo. Il suffit donc de supprimer cette dépendance et de la redéployer. Ce problème est dû à la dépendance cyclique.