Сервисные ссылки в OSGi - PullRequest
       63

Сервисные ссылки в OSGi

8 голосов
/ 04 декабря 2009

Как только экземпляр службы OSGi извлекается из контекста пакета, он становится недействительным при остановке службы?

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

Полагаю, это сводится к тому, что фактически делает получение службы (через ServiceTracker) из другого пакета в контейнере OSGi, создает ли он новый экземпляр или дает вам указатель на экземпляр, зарегистрированный в контейнере?

Существуют ли какие-либо опасности в использовании экземпляра службы после остановки службы?

Ответы [ 6 ]

5 голосов
/ 05 декабря 2009

Это очень хороший вопрос, поэтому я покопался в спецификации в поисках окончательного ответа. Оказывается, что существует целый раздел, посвященный этой проблеме - см. Раздел 5.4 Устаревшие ссылки , начиная со страницы 132 из Основные спецификации OSGi Service Platform, выпуск 4, версия 4.2 .

Чтобы ответить на ваш вопрос согласно спецификации:

Поведение службы, которая становится незарегистрированной, не определено. Такие услуги может продолжать работать должным образом или выдавать исключение по своему усмотрению.

И для предотвращения потенциальных проблем:

Пакеты должны прослушивать события, сгенерированные платформой, чтобы очистить и удалить устаревшие ссылки.

Спецификация также дает несколько советов, как минимизировать последствия устаревших ссылок.

2 голосов
/ 04 декабря 2009

Вы правы в том, что это противоречит динамической природе OSGi. Я считаю, что нет никакой гарантии, что сервис будет доступен, хотя разные реализации контейнеров и сервисов OSGi могут вести себя по-разному.

Например, если служба была создана и зарегистрирована в Spring DM, то полученная служба фактически является прокси-сервером на основе Spring для базовой реализации, и реализация все еще может исчезнуть. Таким образом, сервисная ссылка, которая ссылается непосредственно на реализацию, может удерживать этот объект от удаления, тогда как ссылка на основе прокси не будет.

1 голос
/ 28 января 2010

Как только экземпляр службы OSGi извлекается из контекста пакета он становится недействительным, когда служба остановлен?

Нет, сама ссылка не становится недействительной. Пока что-то внутри контейнера удерживает его, оно также не может быть GC'ed.

Однако, будет ли он по-прежнему полезен, зависит только от самой реализации сервиса, а не от контейнера.

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

В самих спецификациях указывается, что такие ссылки не должны храниться, но разработчик должен позаботиться о правильной реализации спецификаций; означает, что нет никакого противоречия, есть только тот факт, что вы можете внедрять и развертывать пакеты, которые ведут себя неправильно в соответствии со спецификациями.

Я полагаю, это сводится к тому, что получение службы (через ServiceTracker) из другого пакета в контейнере OSGi фактически делает, создает ли он новый экземпляр или дает вам указатель к экземпляру, который зарегистрирован в контейнере?

Контейнер не создает новые экземпляры сервисов, кроме случаев, когда задействован ServiceFactory (см. Спецификации). Поиск службы всегда должен указывать на зарегистрированный экземпляр в контейнере.

Есть ли какие-либо опасности в использовании экземпляра службы после остановки службы?

Это зависит только от реализации сервиса; однако, делая это в пакете, вы автоматически создаете пакет, который не соответствует спецификациям.

На практике многие службы реализованы для освобождения ресурсов и ссылок и больше не будут отвечать должным образом.

1 голос
/ 04 декабря 2009

Спецификация OSGi гласит:

Связки - это объекты, которые видны в обычном прикладном программировании. За Например, когда пакет остановлен, все его услуги будут незарегистрированными.

Таким образом, вы не сможете получить услугу из остановленного пакета. Но технически это может быть возможно использовать, по крайней мере, до тех пор, пока вы держите ссылку на объект службы (никто не может отобрать его у вас, и он не будет GC'd). Но я не думаю, что пользоваться услугой можно, кроме как. Это может зависеть от других ресурсов пакета, которые недоступны после остановки пакета.

0 голосов
/ 09 февраля 2010

Сервисная ссылка никогда не должна храниться в качестве справочной. Вы всегда должны искать сервис во время выполнения. Это связывает вас с API OSGI, что не всегда нужно.

Посмотрите на - OSGI serviceTracker - ОСГИ декларативные услуги - OSGI BluePrint - Spring DM - Peaberry - iPojo

, которые позаботятся о динамичности для вас, большинство из них без OSGI API для использования.

С уважением,

Leen Toelen

0 голосов
/ 08 декабря 2009

Относительно вашего вопроса, опасно ли использовать экземпляр службы после остановки службы. Для цитирования из спецификации ядра 4.2 (устаревшие ссылки 5.4):

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

Я не хочу цитировать здесь весь раздел спецификации, но следующие предложения являются хорошим обсуждением опасности использования устаревших ссылок:

Устаревшая ссылка - это ссылка на объект Java, который принадлежит загрузчику классов пакета, который остановлен или связан с сервисным объектом, который не зарегистрирован. Стандартная Java не предоставить любые общие средства для очистки устаревших ссылок и связать разработчики должны тщательно анализировать свой код, чтобы гарантировать, что устаревшие ссылки удалены.

Устаревшие ссылки потенциально вредны, потому что они мешают Java сборщик мусора от сбора классов, и, возможно, экземпляры, остановленных связок. Это может привести к значительному увеличению памяти использование и может привести к сбою обновления собственных библиотек кода. Связки, использующие службам настоятельно рекомендуется использовать либо Service Tracker, либо Декларативные услуги.

...