Служба OSGi все еще "управляется OSGi", когда она получена не-OSGi кодом? - PullRequest
3 голосов
/ 01 февраля 2012

Как новичок в OSGi, я пытаюсь обернуть голову вокруг границ среды выполнения OSGi.Мое приложение, которое не основано на OSGi, то есть не работает в контейнере OSGi, запускает контейнер OSGi, в который мы разворачиваем пакеты OSGi во время выполнения.Некоторые из этих пакетов регистрируют сервисы.Позже, в нашем коде не OSGi, мы получаем эти сервисы и используем их.

У меня проблемы с тем, чтобы обернуть слабый ум вокруг границ OSGi.Чтобы быть точным, когда я получаю сервис и вызываю один из его методов, могу ли я предположить, что все последующее выполнение выполняется в контейнере OSGi (Felix)?Другими словами, разрешены ли зависимости в этом коде с помощью механизмов модульности OSGi?Или я потерял управление OSGi, потому что я использую сервис из кода, отличного от OSGi?

Если мой вопрос основан на очевидных ошибочных предположениях об OSGi, пожалуйста, не стесняйтесь указывать на них.

Ответы [ 2 ]

1 голос
/ 03 февраля 2012

Чад, чтобы более эффективно ответить на ваш вопрос, я бы хотел знать несколько вещей: 1) Как именно вы получаете сервисную ссылку из внешнего приложения? 2) Является ли внешнее приложение автономным или оно находится внутри другого контейнера? Если так, то есть способы сделать это.

Вопрос, который вы задаете, интересен. Давайте поместим это в контекст. Предположим, что вы можете получить ссылку на сервис OSGi от Феликса из внешнего приложения. Когда вы используете этот сервис, вы будете взаимодействовать с ним через интерфейс. В этом интерфейсе в OSGi вы будете иметь ссылки на операторы импорта, которые будут использоваться в сигнатурах методов интерфейса, а также в любых конечных атрибутах. Эти операторы импорта будут иметь соответствующие зависимые библиотеки, определенные в вашем файле pom.xml.

Чтобы использовать службу внешним приложением, вам нужно будет опубликовать файл API ".jar", который будет содержать интерфейс и ссылаться на зависимости интерфейсов. Ваше внешнее приложение должно будет использовать этот API и, скорее всего, соберет его в каталог lib вашего .war, .jar или .ear файла. Из-за этого ни одна из зависимостей вашего внешнего приложения не может конфликтовать с вашими зависимостями API.

Пока вы можете использовать API, вы правы, ни одна из зависимостей SPI не имеет значения. Вы можете использовать Spring 3.0.4.RELEASE во внешнем приложении и по-прежнему использовать Spring 2.5.6.SNAPSHOT в своем приложении OSGi. Пока API не имеет каких-либо зависимостей, которые конфликтуют с внешним приложением, вы должны быть в порядке. Хитрость заключается в том, что вам нужно поместить ваши интерфейсы в минимальный файл .jar в качестве вашего API, а затем поместить детали реализации в SPI. Ваш внешний AP будет использовать API, а внутри OSGI вы будете использовать как API, так и SPI.

Пожалуйста, дайте мне знать, если это поможет.

0 голосов
/ 01 февраля 2012

Если вы можете получить услугу, то зависимости удовлетворяются по определению, поскольку пакеты не могут предоставлять услуги, если не удовлетворены их зависимости. Оказание услуг снаружи ничего не меняет.

...