Look at org.apache.felix.framework.util.Util#isServiceAssignable This is the method called to filter ServiceReference for a given bundle. This method clearly indicate that it will remove any service that has an unkown interface for the bundle.
On Sat, Mar 21, 2009 at 00:58, Richard S. Hall <[email protected]> wrote: > I am fairly certain the spec says if the requester does not have a wire to > the package, then it should receive the service reference. In this case the > framework assumes the caller is using reflection to access the service > object. Here are the comments in ServiceReferenceImpl.isAssignableTo(): > > // There are three situations that may occur here: > // 1. The requester does not have a wire for the package. > // 2. The provider does not have a wire for the package. > // 3. Both have a wire for the package. > // For case 1, we do not filter the service reference since we > // assume that the bundle is using reflection or that it won't > // use that class at all since it does not import it. For > // case 2, we have to try to load the class from the class > // loader of the service object and then compare the class > // loaders to determine if we should filter the service > // refernce. In case 3, we simply compare the exporting > // modules from the package wiring to determine if we need > // to filter the service reference. > > If you have a simple example where this is not working, create a JIRA issue > for it and attach the example. > > -> richard > > On 3/20/09 6:33 PM, Guillaume Nodet wrote: >> >> 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]
