Чому обмеження використання порушуються, коли обидві ланцюги закінчуються в одному пакеті?


151

У мене є чотири пучки, кожен з яких містить лише маніфест. Пучки є

  • app який імпортує com.example.foo.fragment іcom.example.bar
  • foo який експортує com.example.foo;uses:=com.example.foo.cfg
  • foo.fragmentщо є фрагментом, приєднаним до fooцього експортуcom.example.foo.fragment таcom.example.foo.fragment.cfg;uses:=com.example.foo.fragment
  • barякий експортує com.example.barта імпортуєcom.example.foo

Графік залежності рівня розшарування :

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

Коли я встановлюю ці пачки відразу в JBoss AS 7.2, вони працюють чудово. Але якщо я встановлюю appпакет після інших, або вперше, або після успішного запуску, а потім видалення його, виникає наступне порушення обмеження:

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

Повні маніфести:

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

Мені не вдалося відтворити вищевказану помилку в автономному апараті Фелікс 4.2.1.

У чому причина такої поведінки? Якщо я видалю Fragment-Host: com.example.fooрядок із foo.fragmentманіфесту, я можу перевстановити його appпросто без помилок. Це помилка в JBoss AS 7.2?


1
Я згоден, це досить дивно. Мені спокуса назвати цю помилку в реалізації рамки JBoss AS, і в цьому випадку про неї слід повідомити у списку розсилки JBoss та / або видати трекер.
Ніл Бартлетт

Трохи розібравшись з цим, я помітив, що це відбувається лише в тому випадку, якщо моя програма не розгорнута при запуску JBoss. Можливо, є ще один експорт пакетів org.hibernate.annotations, і платформа OSGi вирішує це як залежність пакета Spring ORM, якщо платформа OSGi запускається без мого додатка. Потім я розгортаю свою програму, і OSGi не вдається її вирішити, оскільки вона не сумісна з org.hibernate.annotationsпакетом, вирішеним до Spring ORM-пакету. Це звучить доцільно?
Еміль Лундберг

4
Зараз я також розпочав дискусію в спільноті JBoss: community.jboss.org/thread/229824
Еміль Лундберг

@NeilBartlett Я щойно з'ясував відповідь на питання 2: експорт пакету org.hibernate.annotations- це фрагмент Fragment-Host: com.springsource.org.hibernate.
Еміль Лундберг

1
Це схоже на помилку. Пакети фрагментів повинні діяти так, ніби вони є частиною їхнього вузлового зв’язку. Схоже, в деяких випадках JBoss розглядає фрагмент як окремий пакет під час перевірки послідовності класу.
jgibson

Відповіді:


1

Вам не потрібно імпортувати foo.fragment в додаток, залежність якого буде вирішено з foo. тож просто видаліть цю залежність і повторно розгорніть її. Це питання через циклічну залежність.


3
Це не циклічна залежність . Це було б циклічно, якби foo.fragment залежав від програми. Однак додаток залежить від foo.fragment, тому циклу немає. Однак явна залежність від програми до foo.fragment може бути непотрібною, це правда.
vog
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.