Hi Neil, I had switched out the DS components for some framework API based code (a servicetracker that just logs the add/modify/remove and invokes inside the add method) and these are working ok. I think my hacky classloader is honouring the compatibility of package+version (it does explicitly check for a match of both, and I've yet to see a classcast).
I assumed (and you've stated explicitly) that SCR isn't doing any freaky magic, it's just using the framework API - so I'm still quite confused as to why I'm seeing different behaviour. Time to crank up the debugger and step over the SCR code, hopefully I'll see what I'm missing/doing wrong there. While I did want all the services loaded eagerly, it may be a lot clearer to use FindHook and use the caller's bundle for classloading (that should at least absolutely remove the potential for package collisions?). Will give this a try if I don't gleam anything from debugging. Thanks Neil, this isn't the first time you've helped me out - now I've some confidence and fresh avenues to try =) Best regards, Caspar On 5 April 2013 16:21, Neil Bartlett <[email protected]> wrote: > My guess is that this is due to service compatibility filtering... it's not > an SCR problem at all. > > OSGi normally checks whether the consumer and provider of a service are > compatible: i.e., if they both import the service interface from the same > export. This is very important because it prevents class cast exceptions or > worse errors when you go and get a service instance. However if the > provider is a proxy, it's perfectly possible to create an instance of an > interface without actually importing the interface, so the service registry > thinks that it is incompatible with your consumer. > > This filtering happens directly in the service registry, not at the SCR > level. So you can confirm it by using the low-level API and seeing whether > you get the same result. Calling BundleContext.getServiceReferences() will > be enough. You can also call BundleContext.getAllServiceReferences()... > this turns off the compatibility filtering. If the latter call gives you > the service but the former does not, then we have confirmed that the cause > is compatibility filtering. > > If so, then the solution is to make sure your provider bundle (the one that > generates the proxies and registers them) has *no imports at all*. When > OSGi sees this, it works out that you're doing something special and it > turns off the filtering. This may require you to separate the > proxy-registering code out into a small bundle that you have created > specifically for the purpose. This is what most Remote Services > implementations do, for example. > > Hope this helps, > Neil > > > > On Fri, Apr 5, 2013 at 4:08 PM, Caspar MacRae <[email protected]> wrote: > > > Hello, > > > > I have a bit of strange problem and I'm hoping somebody reading has > > experienced something similar and can tell me where I'm going wrong. > > > > I'm registering a number of services that are proxies, these show up in > the > > console and I can use the framework API to look up valid references and > > invoke methods. > > > > The problem is these aren't being picked up by SCR managed components - > > they just show as unsatisfied. I replaced the proxies with a concrete > > implementation (non-DS, framework registered) and the dependencies were > met > > and the DS components activated - so everything appears to work > > independently, but not in concert it seems. > > > > I am creating and registering these services via a SCR managed component > > but not in any lifecycle methods. Just using standard > > java.lang.reflect.Proxy#newProxyInstance() with hacky custom classloader > > that simply delegates to the bundles exporting the various > > interfaces/classes used in the proxied interfaces. > > > > Also tried to create a simple test case with pax-exam but I'm unable to > > reproduce it there. > > > > > > I'm at loss looking at my own code, so will start digging into the Felix > > SCR code to understand how it uses the framework API to find 'n' bind, > > hopefully that will shed some light on my problem. > > > > > > Any suggestions gratefully received, thanks for listening, > > > > > > regards, > > Caspar > > >
