OSGI Declarative Services (DS): Что является хорошим способом использовать сервисные экземпляры компонента
Помещение его в пространствах имен делает объявления локальными для того пространства имен для файла (в случае, если у Вас есть несколько пространств имен в файле), но если у Вас только есть одно пространство имен на файл тогда, это не имеет большую часть значения, выходят ли они на улицу или в пространстве имен.
using ThisNamespace.IsImported.InAllNamespaces.Here;
namespace Namespace1
{
using ThisNamespace.IsImported.InNamespace1.AndNamespace2;
namespace Namespace2
{
using ThisNamespace.IsImported.InJustNamespace2;
}
}
namespace Namespace3
{
using ThisNamespace.IsImported.InJustNamespace3;
}
3 ответа
Кристоф,
Спасибо за разъяснение этого вопроса относительно исходной версии, но я думаю, вам все же нужно указать, почему третий класс не может быть создан с помощью чего-то вроде DS.
DS вызывает компоненты должны быть опубликованы как службы, поэтому единственный способ «получить» любой компонент из DS - это получить к нему доступ через реестр служб. К сожалению, реестр служб может быть трудно правильно использовать с помощью API нижнего уровня, потому что он динамический, поэтому вам нужно справляться с возможностью того, что службы исчезнут или станут недоступны именно в тот момент, когда вы хотите, чтобы они были доступны, и так далее. . Вот почему существует DS: он дает вам абстракцию для зависимости от сервисов и управления жизненным циклом ваших компонентов на основе доступности сервисов, на которые они ссылаются.
Если вам действительно нужно получить доступ к сервису без использования DS или чего-то подобного (и есть большой выбор «подобных вещей», например Spring-DM, iPOJO, Guice / Peaberry и т. Д.), Вам следует использовать ServiceTracker. Я согласен, что здесь много накладных расходов - опять же, именно поэтому вместо него существует DS.
Чтобы ответить на ваше предложение № (2), нет, вам не следует создавать свой собственный реестр служб, потому что реестр служб уже существует. Если вы создали отдельный параллельный реестр, вам все равно придется обрабатывать всю динамику, но вам придется обрабатывать ее в двух местах вместо одного. То же самое относится и к предложению (3).
Надеюсь, это поможет.
С уважением, Я согласен, что здесь много накладных расходов - опять же, именно поэтому вместо него существует DS.
Чтобы ответить на ваше предложение № (2), нет, вам не следует создавать свой собственный реестр служб, потому что реестр служб уже существует. Если вы создали отдельный параллельный реестр, вам все равно придется обрабатывать всю динамику, но вам придется обрабатывать ее в двух местах вместо одного. То же самое относится и к предложению (3).
Надеюсь, это поможет.
С уважением, Я согласен, что здесь много накладных расходов - опять же, именно поэтому вместо него существует DS.
Чтобы ответить на ваше предложение № (2), нет, вам не следует создавать свой собственный реестр служб, потому что реестр служб уже существует. Если вы создали отдельный параллельный реестр, вам все равно придется обрабатывать всю динамику, но вам придется обрабатывать ее в двух местах вместо одного. То же самое относится и к предложению (3).
Надеюсь, это поможет.
С уважением, Нил
ОБНОВЛЕНО: кстати, хотя в Spring есть бэкдор Container.getBean (), вы заметили, что во всей документации Spring настоятельно рекомендуется не использовать этот бэкдор: чтобы получить бин Spring, просто создайте другой бин, который ссылается на Это. То же самое относится и к DS, то есть лучший способ получить компонент DS - создать другой компонент DS.
Также обратите внимание, что в мире OSGi, даже если вы используете Spring-DM, нет простого способа просто вызовите getBean (), потому что вам сначала нужно получить Spring ApplicationContext. Это сама служба OSGi, так как же получить ее?
christoph, не знаю, действительно ли я понимаю вашу проблему. за пр. Пакет A предоставляет услугу с использованием компонента DS:
<service>
<provide interface="org.redview.lnf.services.IRedviewLnfSelectedService"/>
Пакет B требует эту услугу с использованием компонента DS:
<implementation class="ekke.xyz.rcp.application.internal.XyzApplicationLnfComponent"/>
как только пакет A предоставляет услугу, пакет B "получает" его через метод bind () класса реализации :
public class XyzApplicationLnfComponent {
public void bind(IRedviewLnfSelectedService lnfSelectedService) {
// here it is
}
надеюсь, что это поможет экке
Простой способ: вставьте компонент DS в свой класс Activator с помощью Riena: http://wiki.eclipse.org/ Riena_Getting_Started_with_injecting_services_and_extensions
Затем вы можете вызывать его отовсюду: Activator.getDefault (). GetWhateverService ()