@Reference field injected osgi services randomly coming up "null"

Question

We have a decent sized osgi application which consist of approximately 80 custom service bundles with an additional 20 to 30 3rd party bundle dependencies at runtime (we are running R7 flavor of osgi). When we started this project we would typically use field injection of our services with the @Reference annotation and had no issues at all, but now, we are seeing more and more that these injected dependencies are sometimes randomly coming up as null - one way we have found to fix the issue is to replace the field injection with method injection of the services.

What I have noticed is, that where the injected services are typically coming up null is in our component services, which are effectively just Java classes with the @Component annotation slapped on, but which do not implement a "ProviderType" or "ConsumerType" interface (our REST endpoints are like this). We are already currently setting these component's property of "immediate=true" but this doesn't seem to have any effect on the injected services randomly coming up null.

When we check the list of bundles - all the correct bundles appear to be Active and sometimes even the services appear to be fine (NO Unsatisfied References) which is totally mind boggling.

Anyone who may have some insight on why this would be occurring?

Some ongoing abnormalities / possible causes: Since the beginning of the project we have seen the following error with almost all of our REST endpoints but don't know exactly why the framework thinks its seeing duplicate classes and methods. Both

fully.qualified.class.path.CustomServiceRest#doStuff and fully.qualified.class.path.CustomeServiceRest#doStuff are equal candidates for handling the current request which can lead to unpredictable results Dec 13, 2018 2:41:45 PM org.apache.cxf.jaxrs.model.OperationResourceInfoComparator compare WARNING: Both fully.qualified.class.path.CustomServiceRest#doSomeOtherStuff and fully.qualified.class.path.CustomServiceRest#doSomeOtherStuff are equal candidates for handling the current request which can lead to unpredictable results

Recently we have added an osgi WebSocket service which required an addition of another Jetty dependency bundle and there has been some concern about having the two Jetty bundles playing nice in the runtime mix.

Answer 1

After much wrestling with this issue, what was found - Each of our RestEndpoint bundles contained a JaxRsApp class which extnends javax.ws.rs.core.Application and we were adding each of our RestEndpoint static classes to the Set> set within the Overridden getClasses() method, however, each of our RestEntpoints classes are annotated with @Component, and each @Component has the service property set to that respective endoints class name, and as such what we believe was happening is that each class was being registered twice (once by the JaxRsApp and once by the SCR with the @Component notation), hence the duplicate warning message whenever we would hit any of the restenpoints with a Postman test or the UI made a rest call.

In addition, by removing the static registrations from the JaxRsApp file (so we are now only registring the restendpoint components with SCR), not only did the warning go away, but also the null service issue cleared up. So we believe that prior to the change, the SCR was in fact injecting the dependency services, but somehow with the "duplicated" service endpoints, the dependency services were being injected into the JaxRsApp registered serice classes? I'm not 100% sure so if someone here can explain it would be greatly apprecitated.

In any case it works now.