Hi You might want to enable DEBUG logging for the Felix SCR to see why SCR would potentially see a service but not use for satisfy a requirement. See [1] for the property to set.
Regards Felix [1] http://felix.staging.apache.org/documentation/subprojects/apache-felix-service-component-runtime.html#configuration Am 08.04.2013 um 07:07 schrieb Caspar MacRae: > 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 >>>> >>> >> >> -- Felix Meschberger | Principal Scientist | Adobe --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
