web-dev-qa-db-fra.com

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

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

  • app qui importe com.example.foo.fragment et 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 et 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 du bundle:

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

Lorsque j'installe ces bundles en une seule fois dans JBoss AS 7.2, ils fonctionnent très bien. Mais si j'installe le bundle app après les autres, soit pour la première fois, soit après avoir correctement démarré puis désinstallé, ce qui suit utilise la violation de contrainte 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 le Fragment-Host: com.example.foo ligne du foo.fragment manifeste, je peux réinstaller app très bien sans erreurs. Est-ce un bogue dans JBoss AS 7.2?

osgijboss7.xapache-felix
151
Emil Lundberg

Vous n'avez pas besoin d'importer foo.fragment dans l'application, votre dépendance résoudra à 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.

1
user3555572