osgi - OSGi 组件模型中的捆绑内和捆绑间相互依赖关系

Question

在我当前的应用程序中，我在几个地方遇到了这种模式:我在一个 bundle 中有两个服务接口(interface)，它们执行不同但相关的工作。

interface Service1 { ... }

interface Service2 { ... }

并希望有单例组件实现两者，但发现每个组件都需要对另一个的引用:

public class Service1Impl implements Service1 { 

    private Service2 service2;
    ...

}

public class Service2Impl implements Service2 { 

    private Service1 service1;
    ...

}

三个 OSGi 组件模型(DS、Blueprint 和 iPOJO)中的哪一个允许这样做:1)当 Service1Impl 和 Service2Impl 在同一个包中时； 2) 当它们在不同的包中时？

Answer 1

声明式服务规范，版本 1.1:

112.3.5 Circular References

It is possible for a set of component descriptions to create a circular dependency. For example, if component A references a service provided by component B and component B references a service provided by component A then a component configuration of one component cannot be satisfied without accessing a partially activated component instance of the other component. SCR must ensure that a component instance is never accessible to another component instance or as a service until it has been fully activated, that is it has returned from its activate method if it has one.

Circular references must be detected by SCR when it attempts to satisfy component configurations and SCR must fail to satisfy the references involved in the cycle and log an error message with the Log Service, if present. However, if one of the references in the cycle has optional cardinality SCR must break the cycle. The reference with the optional cardinality can be satisfied and bound to zero target services. Therefore the cycle is broken and the other references may be satisfied.

蓝图规范明确允许这样做，前提是依赖循环的至少一个成员将其他成员作为属性而不是参数(121.2.6 循环依赖):

When a member of a cycle is requested to provide a component instance, the Blueprint Container must break the cycle by finding one breaking member in the cycle’s members. A breaking member must use property injection for the dependency that causes the cycle. The Blueprint Container can pick any suitable member of the cycle for breaking member, if no such member can be found, then initialization fails or the getComponentInstance method must throw a Component Definition Exception.

A breaking member must return a partially initialized component instance when it is asked to provide an object. A partially initialized object has done all possible initialization but has not yet been called with the initMethod (if specified) nor has it been injected any of the properties that causes a cycle. The finalization of the partially initialized component instance must be delayed until the breaking member has been injected in all referring members of the cycles. Finalization means injecting any remaining unset properties and calling of the initMethod, if specified.

The consequence of partially initialized component instances is that they can be used before they have all properties set, applications must be aware of this.

All partially initialized component instances must be finalized before the Blueprint Container enters the Runtime phase and before a call to the getComponentInstance method returns a component instance. User code that causes a dynamic cycle by recursively calling the getComponentInstance method must be detected and cause a failure, these cycles cannot be broken.

All detected cycles should be logged.

对于 iPOJO

Your specific situation is supported. I can't talk for other situations without knowing further description though.

(在邮件列表中收到答复)。