felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Neil Bartlett <njbartl...@gmail.com>
Subject Re: SCR not binding proxy dependency
Date Fri, 05 Apr 2013 15:21:11 GMT
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,

On Fri, Apr 5, 2013 at 4:08 PM, Caspar MacRae <earcam@gmail.com> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message