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

151

J'ai quatre paquets, chacun contenant seulement un manifeste. Les bundles sont

appqui importe com.example.foo.fragmentetcom.example.bar
foo qui exporte com.example.foo;uses:=com.example.foo.cfg
foo.fragmentqui est un fragment attaché à fooces exportations com.example.foo.fragmentetcom.example.foo.fragment.cfg;uses:=com.example.foo.fragment
barquelles exportations com.example.baret importationscom.example.foo

Graphique de dépendance au niveau du bundle :

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

Lorsque j'installe ces bundles en même temps dans JBoss AS 7.2, ils fonctionnent très bien. Mais si j'installe le appbundle après les autres, soit pour la première fois, soit après avoir démarré et désinstallé avec succès, la violation de 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 pu reproduire l'erreur ci-dessus dans Apache Felix 4.2.1 autonome.

Quelle est la cause de ce comportement? Si je supprime la Fragment-Host: com.example.fooligne du foo.fragmentmanifeste, je peux réinstaller apptrès bien sans erreurs. Est-ce un bogue dans JBoss AS 7.2?

osgi jboss7.x apache-felix

— Emil Lundberg
source

Je suis d'accord que c'est assez bizarre. Je suis tenté d'appeler cela un bogue dans l'implémentation du framework JBoss AS, auquel cas il devrait être signalé sur la liste de diffusion JBoss et / ou le suivi des problèmes.

— Neil Bartlett

Après avoir un peu fouillé avec lui, j'ai remarqué que cela ne se produit que si mon application n'est pas déployée au démarrage de JBoss. Peut-être qu'il y a, après tout, un autre ensemble d'exportation org.hibernate.annotations, et la plate-forme OSGi résout cela en tant que dépendance du bundle Spring ORM si la plate-forme OSGi démarre sans mon application. Ensuite, je déploie mon application et OSGi ne parvient pas à la résoudre car elle n'est pas compatible avec le org.hibernate.annotationsbundle résolu en bundle Spring ORM. Cela semble-t-il faisable?

— Emil Lundberg

J'ai maintenant aussi commencé une discussion dans la communauté JBoss: community.jboss.org/thread/229824

— Emil Lundberg

@NeilBartlett Je viens de trouver la réponse à la question 2: l'exportation du bundle org.hibernate.annotationsest un fragment avec Fragment-Host: com.springsource.org.hibernate.

— Emil Lundberg

Cela ressemble à un bug. Les bundles de fragments sont censés agir comme s'ils faisaient partie de leur bundle hôte.Il semble que dans certains cas, JBoss traite le fragment comme un bundle séparé lors de l'exécution du contrôle de cohérence du chemin de classe.

— jgibson

Vous n'avez pas besoin d'importer foo.fragment dans l'application que votre dépendance résoudra à partir de foo. alors supprimez simplement cette dépendance et redéployez-la. Ce problème est dû à la dépendance cyclique.

— user3555572
source

Ce n'est pas une dépendance cyclique . Ce serait cyclique si foo.fragment dépendait de l'application. Cependant, l'application dépend de foo.fragment, il n'y a donc pas de cycle. Cependant, la dépendance explicite de l'application à foo.fragment peut être inutile, c'est vrai.

— vog le