Another problem i've hit is that if C does not even import foo and the service exported by A as one of its exposed interface from the foo package, C won't be able to use the service. This can be problematic because C may be able to use some of the interfaces exposed by that service. I'm not sure what the spec says about such scenario. If this is not mandatory, I think the behavior could be changed in such a case. The getServiceReference() should exclude service which have an incompatible class between bundles A and C, but not exclude services which have classes not known to C imho.
This can easily be used when using spring-dm and the export-all attribute which exports all the classes and interfaces (leading to the service being usually unusable, unless you see the implemenation class itself). On Fri, Mar 20, 2009 at 23:24, Karl Pauls <[email protected]> wrote: > 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] > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
