Java OSGi声明性服务在手动安装捆绑包时不绑定服务

我正在努力实现的目标

使用netbeans模块化系统为我们准备应用程序，因为我们通过ApacheFelix使用声明性服务在OSGi中实现模块。以下是模块设置：

模块A-提供服务A和B 模块B-提供服务C、参考服务A和B 模块C-提供服务D，处理模块A和B的安装 模块D-参考服务D和B。 模块C通过以下代码安装模块：

BundleContext context = FrameworkUtil.getBundle(class).getBundleContext();
Bundle tcp = context.installBundle("file:Location");
tcp.start();

在这里，一切安装和启动都不会出错。但是，声明的引用没有绑定到服务

为了更具体地了解所有东西是如何结合在一起的，我将代码添加到github中。记住将文件中的行：模块C、dk.sdu.ace.dp.Controller、第27-28行更改为模块B和A的位置

模块A是TCP服务器OSGi捆绑包 模块B是游戏世界OSGi包 模块C是依赖控制器OSGi包 模块D是服务器引擎OSGi包。 到目前为止我都试过了

我试着确保安装的构建顺序，以便在模块B之前安装模块A，甚至相反，只是为了确保。我甚至在第二个bundle达到启动状态后尝试安装bundle。 在模块A启动后调用模块B上的更新。 如果我在安装捆绑包时需要手动注册和提供不同的服务，我会查找到任何内容，或者根本不理解答案。。 我已经尝试了很多愚蠢的事情，在这里尝试或描述可能没有意义。 额外问题

当通过bundlecontext安装和启动时，声明性服务是否应该自动将提供程序与引用绑定在一起

---

这种构造应用程序的方法是可行的，还是我们应该采用另一种方法？如果是，哪一个

您的DS引用使用的是可选基数，而不是贪婪基数。出于历史向后兼容性的原因，不情愿的策略选项是默认选项

---

在不情愿的情况下，如果以后注册了其他/更好的服务，例如在捆绑使用服务之后启动提供服务的捆绑，则引用不会反弹。有了贪婪，引用就会反弹

OSGi没有开始订购，Felix SCR在这方面非常出色。其美妙之处在于所有依赖项都是动态绑定的。顺序很重要的系统是糟糕的OSGi系统。您可以使用Apache Felix gogo并使用scr:list ad scr:info命令查看您对服务不满意的原因。我找不到确切的方法，但这只是通过在每个引用用法中添加policy=dynamic policy option=greedy来实现的吗？policy option=greedy是您所需要的。如果您想使用policy=dynamic，那么您的代码需要随时准备注入，而不仅仅是在组件激活期间。我认为您是对的，但是我的项目还没有准备好处理添加了policy选项的新版本，我使用v.1.1.0，其中我需要在xmlns:scr中使用v1.4.0。所以我不能在不更新项目依赖项的情况下立即使用它。但是我在做这件事时遇到了麻烦…policy option=greedy是在DS v1.2.0中添加的。感谢BJ，这是问题的一部分，但我们必须将整个项目转换为纯OSGi，因为我们无法更新依赖项以使用较新的OSGi和equinox。在切换到ApacheFelixGogo之后，在修复了一些错误之后，它工作得很顺利。