Well, a call to the BundleContext.getServiceReference(s) method is going to filter based on whether you can see the version of the interface of the service or not. In certain scenarios, you couldn't use the service because you see a different version of the interface then the service actually implements (so you would get a classcast exception). Therefor, these services are filtered away. In case you still want to see them (for example because you are going to use reflection) you can use the getAllServiceReferences method.
Why is that happening? Well, there are a couple of scenarios but a simple one is: A imports foo from B C imports foo from D now if A exports a service with an interface out of foo then C can not use that service because it gets foo from a different provider. That is why bundles should generally import what they export. In your case, try to use getAllServiceReferences and see whether that helps. Then you can check where your bundle wiring goes wrong. Hope that helps. regards, Karl On Fri, Mar 20, 2009 at 10:50 PM, Patrick Forhan <[email protected]> wrote: > This is a generic OSGi service question, I think. We use a mix of > Spring-DM and Felix-SCR for services, but have never had an issue like > this. > > Are there any circumstances where a service won't be found by someone > looking for it? My impression is that services are referenced by a > string version of their class name, so there shouldn't be class > loading differences, right? > > Basically, we have this structure: > > bundle mvc.framework > IView > ICommand > ... and a couple of services looking for instances of those interfaces. > > bundle authentication.ui > AuthenticationView implements IView > AuthenticationCommand implements ICommand > > For some reason, AuthenticationCommand gets found by the service > looking for ICommand interfaces, but AuthenticationView does not. > When I do a "services" on authentication on the felix cmd line, both > are showing properly. But when I do a "services -u" on mvc.framework, > only AuthenticationCommand shows up. > > This feels like some filtering is in place, but we've stripped all of > that out. This code is only 2 days different from a working version > of our spring-dm context files, and we can't see what's going on. > > Pat. > > -- > Defy mediocrity. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Karl Pauls [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
