Perché i vincoli di utilizzo vengono violati quando entrambe le catene finiscono nello stesso pacchetto?

151

Ho quattro fasci, ognuno contenente solo un manifest. I pacchi sono

appquale importa com.example.foo.fragmentecom.example.bar
foo che esporta com.example.foo;uses:=com.example.foo.cfg
foo.fragmentquale è un frammento allegato a footali esportazioni com.example.foo.fragmentecom.example.foo.fragment.cfg;uses:=com.example.foo.fragment
barquali esportazioni com.example.bare importazionicom.example.foo

Grafico delle dipendenze a livello di pacchetto :

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

Quando installo questi bundle contemporaneamente in JBoss AS 7.2, funzionano perfettamente. Ma se installo il appbundle dopo gli altri, per la prima volta o dopo averlo avviato e disinstallato correttamente, si verifica la seguente violazione dei vincoli:

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

I manifesti completi sono:

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

Non sono stato in grado di riprodurre l'errore sopra riportato in Apache Felix 4.2.1 autonomo.

Qual è la causa di questo comportamento? Se elimino la Fragment-Host: com.example.fooriga dal file foo.fragmentmanifest, posso reinstallare appcorrettamente senza errori. È un bug in JBoss AS 7.2?

osgi jboss7.x apache-felix

— Emil Lundberg
fonte

Sono d'accordo che questo è piuttosto strano. Sono tentato di chiamare questo un bug nell'implementazione del framework JBoss AS, nel qual caso dovrebbe essere segnalato nella mailing list di JBoss e / o nel tracker dei problemi.

— Neil Bartlett,

Dopo averlo esplorato un po ', ho notato che ciò si verifica solo se la mia applicazione non viene distribuita all'avvio di JBoss. Forse c'è, dopo tutto, un altro pacchetto di esportazione org.hibernate.annotations, e la piattaforma OSGi lo risolve come dipendenza del pacchetto Spring ORM se la piattaforma OSGi si avvia senza la mia applicazione. Quindi distribuisco la mia applicazione e OSGi non riesce a risolverlo perché non è compatibile con il org.hibernate.annotationspacchetto risolto con il pacchetto Spring ORM. Sembra fattibile?

— Emil Lundberg,

Ora ho anche iniziato una discussione nella comunità JBoss: community.jboss.org/thread/229824

— Emil Lundberg,

@NeilBartlett Ho appena capito la risposta alla domanda 2: l'esportazione del bundle org.hibernate.annotationsè un frammento con Fragment-Host: com.springsource.org.hibernate.

— Emil Lundberg,

Sembra un bug. I bundle di frammenti dovrebbero agire come se fossero parte del loro bundle host. Sembra che in alcuni casi JBoss stia trattando il frammento come un bundle separato quando esegue il controllo di coerenza del percorso di classe.

— Jgibson,

Non è necessario importare foo.fragment in app la cui dipendenza si risolverà da foo. quindi basta rimuovere quella dipendenza e ridistribuirla. Questo problema è dovuto alla dipendenza ciclica.

— user3555572
fonte

Questa non è una dipendenza ciclica . Sarebbe ciclico se foo.fragment dipendesse dall'app. Tuttavia, l'app dipende da foo.fragment, quindi non c'è ciclo. Tuttavia, la dipendenza esplicita dall'app a foo.fragment potrebbe non essere necessaria, è vero.

— Vog