Сервисные ссылки в OSGi
Вот фиксация для ошибок LoaderException, которые Вы, вероятно, найдете если одна из поддевушек типов тип в другом блоке:
// Setup event handler to resolve assemblies
AppDomain.CurrentDomain.ReflectionOnlyAssemblyResolve += new ResolveEventHandler(CurrentDomain_ReflectionOnlyAssemblyResolve);
Assembly a = System.Reflection.Assembly.ReflectionOnlyLoadFrom(filename);
a.GetTypes();
// process types here
// method later in the class:
static Assembly CurrentDomain_ReflectionOnlyAssemblyResolve(object sender, ResolveEventArgs args)
{
return System.Reflection.Assembly.ReflectionOnlyLoad(args.Name);
}
, Который должен помочь с загрузкой типов, определенных в других блоках.
Hope, которая помогает!
6 ответов
Это очень хороший вопрос, поэтому я покопался в спецификации в поисках окончательного ответа. Оказывается, об этой проблеме идет целый раздел - см. Раздел 5.4 Устаревшие ссылки , начиная со страницы 132 в Базовая спецификация платформы сервисов OSGi, выпуск 4, версия 4.2 .
] Чтобы ответить на ваш вопрос в соответствии со спецификацией:
Поведение незарегистрированной службы не определено. Такие услуги могут продолжать работать должным образом или вызывать исключение по своему усмотрению.
И для предотвращения потенциальных проблем:
Пакеты должны прослушивать события, генерируемые платформой для очистки и удаления устаревших Ссылки.
Спецификация также дает несколько советов, как минимизировать последствия устаревших ссылок.
В спецификации OSGi сказано:
Пакеты - это видимые сущности в обычном прикладном программировании. За Например, когда пакет остановлен, все его службы будут отменены.
Таким образом, вы не сможете получить службу из остановленного пакета. Но технически его можно использовать, по крайней мере, до тех пор, пока у вас есть ссылка на объект службы (никто не может забрать его у вас, и он не будет GC'd). Но я не думаю, что пользоваться услугой безопасно. Это может зависеть от других ресурсов пакета, которые недоступны после остановки пакета.
Вы правы в том, что это противоречит динамической природе OSGi. Я считаю, что нет гарантии, что служба будет доступна, хотя различные реализации контейнеров OSGi и сами службы могут вести себя по-разному.
Например, если служба была создана и зарегистрирована в Spring DM, то полученная служба на самом деле прокси на основе Spring для базовой реализации, и реализация все еще может исчезнуть. Таким образом, ссылка на службу, которая ссылается непосредственно на реализацию, может препятствовать удалению этого объекта, тогда как ссылка на основе прокси - нет.
Regarding your question whether it is dangerous to use a service instance after the service has been stopped. To cite from the 4.2 core spec (5.4 Stale References):
The behavior of a service that becomes unregistered is undefined. Such services may continue to work properly or throw an exception at their на усмотрение.
Я не хочу цитировать здесь весь раздел спецификации, но следующие предложения являются хорошим обсуждением опасности использования устаревших ссылок:
Устаревшая ссылка - это ссылка на объект Java, который принадлежит к загрузчику классов пакета, который остановлен или связан с незарегистрированным служебным объектом. Стандартная Java не предоставить любые общие средства для очистки устаревших ссылок и связать разработчики должны тщательно анализировать свой код, чтобы убедиться, что устаревшие ссылки удаляются.
Устаревшие ссылки потенциально опасны, потому что они мешают Java сборщик мусора от сбора классов и, возможно, экземпляров, остановленных пакетов. Это может привести к значительному увеличению памяти использование и может привести к сбою обновления библиотек собственного кода. Пакеты с использованием services are strongly recommended to use either the Service Tracker or Declarative Services.
После того, как экземпляр службы ОСГИ извлекается из контекста расслоения Это становится недействительным, когда служба остановлен?
Нет, сама ссылка не становится недействительной. Пока что-то в контейнере держит его, он также может не быть GC'DED.
Однако, будет ли он все еще полезным, зависит только от самой реализации службы, а не контейнера.
Мои первоначальные тесты показывают, что экземпляр службы можно использовать даже после того, как сервисный пакет> остановлен, что противоречит моему пониманию динамической природы ОСГИ.
Сама технические характеристики указывают на то, что такие ссылки не должны проводиться, но это зависит от реализатора, чтобы позаботиться о реализации спецификаций правильно; Значит нет противоречия, существует только тот факт, что вы можете реализовать и развернуть пакеты, которые не ведут себя правильно в соответствии с техническими характеристиками.
Я полагаю, что это сводится к получению услуг (через сервопривод) из другого расслоения в контейнере OSGI на самом деле делает это новый экземпляр или дает вам указатель К примеру, который зарегистрирован в контейнере?
Контейнер не создает новые экземпляры услуг, за исключением случаев, если есть вовлеченность услуг (см. Спецификации). Глядя вверх по обслуживанию всегда должен дать вам указатель на зарегистрированный экземпляр в контейнере.
Существуют ли какие-либо опасности использования экземпляра услуг после того, как служба была остановлена?
, что только зависит от реализации службы; Однако, делая так в комплекте, вы автоматически создаете пакет, который не соответствует спецификациям.
На практике многие услуги реализуются для освобождения ресурсов и ссылок и больше не будут реагировать правильно.
Ссылка на службу никогда не должна храниться в качестве ссылки. Вы всегда должны искать службу во время выполнения. Однако это привязывает вас к OSGI api, который не всегда нужен.
Взгляните на - OSGI serviceTracker - Декларативные службы OSGI - OSGI BluePrint - Spring DM - Peaberry {1 }} - iPojo
, которые все заботятся о динамичности для вас, большинство из них не имеют OSGI api для использования.
С уважением,
Лин Тоелен