的相关性选择了使用配置属性

Question

考虑这种情况DS组成：

• 在一个网络管理系统，这是完全的OSGi基于并具有严重的就业服务层SOA概念，它决定将NE管理模块DS部件。
• 有一个DS组件用于跟踪网络资源的配置子代理，当时间合适时，它会根据Neil's article通过出厂配置将管理组件配置为关注该资源。
• 组件集未知，但其配置工厂PID由安装管理组件的专用软件包发布。
• 让我们说有一些当中这些管理组件静态，不愿和强制性的依赖，例如C2需要C1。由于NMS需要添加许多资源，因此可能有许多C1和C2的实例。因此，C2必须绑定到其匹配C1。
• 此选择的标准是一个关键，例如resource-key，它由配置代理为每个资源生成，并通过其（工厂）配置属性提供给每个组件。

现在，这里是我的问题：

问：由于配置属性是唯一部件的激活后可用，怎么能C2绑定到前一个正确的C1被激活，因为他们的关系的本质是什么？

我知道这个问题有不同的口味，有一些机智的答案，如Dynamic target queries in OSGi with DS和here。但是，所有这些答案中缺少的是这样一个事实，即有些情况下组件的每个实例的动态配置都不是已知的，或者至少在它被激活之前是不知道的。

建议： 因为我们必须解决这个问题，只有优雅和OSGi的可接受答案，我能想到的是介绍在参考绑定时间允许这样的事情对于动态宏扩展C2：

@Reference(target="(resource-key=${resource-key})") 
protected void bindC1(C1 c1) 
{ 
    // some binding code 
} 

我们选择了坚持春分DS暂且（！是的，我知道的），因此，我已经修补了IR SCR现在C2会结合的C1适当情况下与resource-key财产“通过使用C2扩大${resource-key-value} S”自己的一套配置匹配的C2。该值在C2.bindC1()内尚未（可）访问。

我想知道为什么这样一个方便的设施从我测试过的每个SCR中都没有。我在这里展示的内容很可能会扩展到使用各种来源，而不仅仅是组件的配置属性。但为什么至少没有证据表明此类功能的正式提案？请赐教！

Answer 1

我没有看到你需要这样的功能。由于您通过组件属性提供resource-key，为什么不只是提供C1引用的目标属性C1.target（请参见DS规范中的112.6.2.1），它以同样的方式引用资源键值？

C1.target = (resource-key=xxx)

的C1.target组件属性的值将覆盖在C1参考注释的target信息。

确定值(resource-key=xxx)比xxx稍微复杂一些，但这比一些宏扩展功能要容易得多。