Необязательные зависимости в OSGI SCR framework

Question

Я использую структуру SCR на платформе OSGI felix для ввода ссылок на службы в моих Компонентах. Это отлично работает, за исключением дополнительных зависимостей. Так что, если у меня есть два компонента Foo и Bar, где Foo приведен ниже:

@Component 
public class FooImpl implements Foo { 
    Log log = LogFactory.getLog(this.getClass()); 
    @Reference(cardinality=ReferenceCardinality.OPTIONAL_UNARY) 
    Bar bar; 

    public void bindBar(Bar bar) { 
     log.info("bar bound: "+bar); 
    } 
    public void unbindBar(Bar map) { 
     log.info("bar unbound: "+bar); 
    } 

    @override 
    public void fooHello() { 
     log.info("Hello, this is an implementation of Foo"); 
    } 
} 

это работает, пока пучок, определяющий интерфейс Бара развертывается в моей OSGi платформе. Если в платформе не задействован компонент реализации Bar, SCR по-прежнему счастлив и активирует мой компонент FooImpl, конечно, без ссылки на любую реализацию Bar. Однако, если интерфейс Bar не развертывается на платформе, SCR падает во время активации моего компонента, вероятно, из-за исключения из проверки моего компонента через отражение, но я не мог определить это окончательно.

Итак, есть ли способ развертывания пакета OSGI с дополнительными зависимостями, которых нет в платформе, которые включают компоненты SCR, которые имеют необязательные ссылки на интерфейсы, исходящие из этих дополнительных зависимостей OSGi?

Answer 1

зависимостей OSGi может быть использован для введения реализаций некоторых типов, как BarImpl класса, реализующим Bar интерфейса, который может быть введен в поле @Reference Bar bar. Необязательные зависимости означают, что ваш компонент OSGi может использовать некоторую услугу, но не требует, чтобы она работала.

Однако, если OSGi не знает тип, который вы пытаетесь использовать в качестве поля, вы получите исключение, и это действительное поведение. Вы просто не можете использовать класс, если его поле имеет неизвестный тип - и его true не только для OSGi, но и для Java в целом.

Хороший подход здесь, чтобы разделить пакет, содержащий Bar реализацию двух пучков:

• bar-api содержащий Bar интерфейс,
• bar-impl содержащий OSGi сервис BarImpl.

bar-api по-прежнему требуется FooImpl, но bar-impl является необязательным и отключить его в консоли Felix не сломается ссылающиеся компонентами.