OSGi组件模型中的束内和束间相互依赖性

Question

在我目前的应用程序中,我在几个地方遇到了这种模式:我在一个捆绑包中有两个服务接口,它们执行不同但相关的工作.

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循环参考

一组组件描述可以创建循环依赖关系.例如,如果组件A引用组件B提供的服务,组件B引用组件A提供的服务,则在不访问其他组件的部分激活的组件实例的情况下,不能满足一个组件的组件配置.SCR必须确保组件实例永远不会被另一个组件实例或服务作为服务访问,直到它被完全激活,即它已从其activate方法返回(如果有).

当SCR尝试满足组件配置时,必须检测到循环引用,并且SCR必须无法满足循环中涉及的引用,并使用Log Service记录错误消息(如果存在).但是,如果循环中的一个引用具有可选的基数,则SCR必须打破循环.具有可选基数的引用可以被满足并且绑定到零目标服务.因此,循环被破坏并且可以满足其他参考.

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

当请求循环的成员提供组件实例时,Blueprint Container必须通过在循环的成员中找到一个破坏成员来打破循环.破坏成员必须对导致循环的依赖项使用属性注入.Blueprint Container可以选择循环中任何合适的成员来破坏成员,如果找不到这样的成员,则初始化失败或getComponentInstance方法必须抛出组件定义异常.

当要求提供对象时,破坏成员必须返回部分初始化的组件实例.部分初始化的对象已完成所有可能的初始化但尚未使用initMethod(如果已指定)调用,也未注入任何导致循环的属性.必须延迟部分初始化的组件实例的最终化,直到在循环的所有引用成员中注入破坏成员.完成意味着注入任何剩余的未设置属性并调用initMethod(如果已指定).

部分初始化组件实例的结果是它们可以在设置所有属性之前使用,应用程序必须知道这一点.

必须在Blueprint Container进入运行时阶段之前和调用getComponentInstance方法返回组件实例之前完成所有部分初始化的组件实例.必须检测通过递归调用getComponentInstance方法导致动态循环的用户代码并导致失败,这些循环不能被破坏.

应记录所有检测到的循环.

对于iPOJO

您的具体情况得到支持.不知道进一步的描述,我不能谈论其他情况.

(在邮件列表上收到回复).