Hello, Brief update: It works fine with Felix but not with Equinox (using Felix SCR 1.6.2, works perfectly with Felix (checked against 4.0.3 and 4.2.1) not with Equinox 3.8.0.v20120529-1548).
Definitely something odd going but I didn't have time to get to the bottom of it. I will hopefully get some time later, at least to try with Equinox 3.9.0.v20130305-2200. cheers, Caspar On 5 April 2013 17:43, Caspar MacRae <[email protected]> wrote: > > 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 >> > >> > >
