Транзитивные зависимости в OSGi

Я получаю NoClassDefFoundError во время выполнения, и я думал, что директива "uses" позволит избежать этого, потому что я думал, что это создает транзитивность (поправьте меня, если я ошибаюсь). Вот моя конфигурация:

Bundle 1 
  Export-package A

Bundle 2 
  Export-package B, uses "A"
  Import-package A

Bundle 3
  Import-package B

Теперь исключение возникает, когда пакет 3 вызывает класс в B, который, в свою очередь, вызывает класс в A. На основе консоли я вижу, что BundleClassLoader ищет класс в пакете 3 (другими словами, в самом себе), но не в пакете 1, где он мог бы его найти. Если я заставлю BND импортировать A в Bundle 3, все будет работать нормально, но это выглядит слишком трудоемко. я чувствую, что я что-то упускаю. Разве равноденствие не должно использовать информацию в манифестах для установки пути к классам пакета? или в худшем случае не должен ли BND обнаруживать зависимость 3 от 1 и импортировать пакет A в манифест 3?

Все мои пакеты active и у меня нет uses нарушений ограничений


java osgi bnd
person Hilikus    schedule 13.12.2012    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Пакет 2 также должен импортировать A. Использование A говорит, что любой пакет, который импортирует мой B, а также импортирует A, должен импортировать тот же A, что и я. Поскольку пакет 2 не импортирует A, это не работает. Кроме того, пакет 3 должен импортировать A, так как B использует A. Любой импортер B также является пользователем A и поэтому должен импортировать A.

person BJ Hargrave    schedule 14.12.2012
comment
извините, у меня есть импорт A в 2, я пропустил его. Обновлю вопрос. Ваша вторая часть - это ответ, который я искал. Но значит ли это, что если A -> B, B -> C, C -> D, D -> E.... то A нужно импортировать B, C, D, E; B необходимо импортировать C, D, E; C необходимо импортировать D, E и т.д.?? звучит очень неудобно - person Hilikus; 14.12.2012
comment
Да, это звучит неудобно, поэтому вам, вероятно, не следует так проектировать свои пакеты. Помните, что ограничение uses существует только потому, что пакет B предоставляет A непосредственно в своих общедоступных интерфейсах, например. как параметр метода. Внутреннее использование НЕ создает ограничение использования. С другой стороны, если вы разработаете свои пакеты таким образом, bnd должен обнаружить это и создать все необходимые ограничения импорта и использования. - person Neil Bartlett; 14.12.2012
comment
Это необходимо. Для конкретного примера подумайте о javax.servlet.http.HttpServlet extends javax.servlet.GenericServlet реализует javax.servlet.Servlet. Это явный случай, когда javax.servlet.http использует javax.servlet. Итак, если ваш пакет реализует сервлет http, вам, очевидно, необходимо импортировать javax.servlet.http. Но вам также необходимо импортировать javax.servlet, поскольку вашему пакету также требуется доступ к этим типам. - person BJ Hargrave; 14.12.2012
comment
@NeilBartlett спасибо за информацию. Я не знал, что это было только тогда, когда он выставлял его в общедоступном интерфейсе, а не во внутреннем использовании. Однако ваш последний комментарий меня смутил. Вы говорите, что BND должен обнаружить случай, подобный тому, что я задал? это не так. Может я неправильно понял ваш комментарий?? - person Hilikus; 14.12.2012
comment
Да, это так... если вы используете пакет, bnd добавит его в файл Import-Package. Вы действительно собрали все эти пакеты с помощью bnd? Можете подробнее описать вашу проблему? - person Neil Bartlett; 14.12.2012
comment
BND добавил пакет used в пакет Import-Package (в моем примере, в Bundle 2), но не добавил Import-Package в исходную вызывающую программу (Bundle 3). Я все собрал с помощью maven-bundle-plugin; хотя и не одновременно - person Hilikus; 14.12.2012