我们有一个大小合适的osgi应用程序，它由大约80个定制服务包以及在运行时具有20至30个第三方捆绑包依赖关系组成（我们正在运行R7风格的osgi）。当我们开始这个项目时，我们通常会使用带有@Reference批注的服务的字段注入，并且完全没有问题，但是现在，我们越来越看到这些注入的依赖项有时会随机变为null-我们采用的一种方式已发现解决问题的方法是将服务的方法注入替换为字段注入。
我注意到的是，在我们的组件服务中，注入的服务通常出现null的地方是我们的组件服务，这些服务实际上是Java类，带有@Component注释，但是没有实现“ ProviderType”或“ ConsumerType”接口（我们的REST端点是这样的）。目前，我们已经将这些组件的属性设置为“ immediate = true”，但这似乎对随机注入null的注入服务没有任何影响。
当我们检查捆绑软件列表时，所有正确的捆绑软件似乎都处于活动状态，有时甚至服务似乎都很好（没有不满意的参考文献），这实在令人难以置信。
可能会对这种情况为什么发生有任何见识的人吗？
一些持续的异常/可能的原因： 从项目开始以来，我们几乎在所有REST端点上都看到了以下错误，但不知道为什么框架会认为它看到重复的类和方法。 两者
fully.qualified.class.path.CustomServiceRest＃doStuff和fully.qualified.class.path.CustomeServiceRest＃doStuff是处理当前请求的等同候选者，这可能导致无法预测的结果 十二月13，2018 2:41:45下午org.apache.cxf.jaxrs.model.OperationResourceInfoComparator比较 警告：fully.qualified.class.path.CustomServiceRest＃doSomeOtherStuff和fully.qualified.class.path.CustomServiceRest＃doSomeOtherStuff都是处理当前请求的候选对象，可能导致无法预测的结果
最近，我们添加了一个osgi WebSocket服务，该服务需要添加另一个Jetty依赖项捆绑包，并且对于使这两个Jetty捆绑包在运行时混合中发挥良好作用存在一些担忧。
答案 0 :(得分：0)
在对该问题进行了很多努力之后，发现了什么-我们的每个RestEndpoint捆绑包都包含一个JaxRsApp类，该类扩展了javax.ws.rs.core.Application，并且我们将每个RestEndpoint静态类添加到Set>中但是，在重写的getClasses（）方法中，我们的每个RestEntpoints类都使用@Component进行了注释，并且每个@Component都将服务属性设置为相应的endints类名，因此，我们认为正在发生的事情是每个类都在注册两次（由JaxRsApp进行一次注册，由SCR使用@Component表示法进行一次注册），因此，只要我们使用Postman测试或UI进行了一次rest调用，都会出现重复的警告消息。
此外，通过从JaxRsApp文件中删除静态注册（因此我们现在仅使用SCR重新注册了restendpoint组件），不仅消除了警告，而且清除了空服务问题。因此，我们认为，在进行更改之前，SCR实际上是在注入依赖项服务，但是以某种方式通过“重复的”服务端点将依赖项服务注入了JaxRsApp注册的服务类中？我不是100％不确定，因此如果有人可以解释这一点，我将不胜感激。
无论如何现在都可以使用。