SCR not binding proxy dependency

[Caspar MacRae <ea...@gmail.com>]

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

Re: SCR not binding proxy dependency

[Caspar MacRae <ea...@gmail.com>]

Hi Felix,

I've been using the three properties for a while, they're very useful (very
fine grained, it's nice to see the method signature match attempts for
example).  Coupled with the SCR commands (thank you!) I've great visibility
and control of the SCR runtime.

I had a chance to follow the normal binding of unproxied service in DS's
DependencyManager, but when switching to proxied services the breakpoints I
placed were never reached - so I think Neil pointed me in right direction
of looking lower down at reference filtering/compatibility in the framework.

I'm just using the default ReferenceStrategy.EVENT, so I will try LOOKUP
and also write a framework ServiceListener to see how these behave in
Equinox.  At the moment it's working well on Felix, and I have a number of
features to deliver - but we run PaxExam tests with both Felix and Equinox
and I don't want to break that, so will return to this soon.

regards,
Caspar


On 9 April 2013 04:45, Felix Meschberger <fm...@adobe.com> wrote:

> 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 <ea...@gmail.com> 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 <nj...@gmail.com> 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 <ea...@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
> >>>>
> >>>
> >>
> >>
>
>
> --
> Felix Meschberger | Principal Scientist | Adobe
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>

Re: SCR not binding proxy dependency

[Felix Meschberger <fm...@adobe.com>]

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 <ea...@gmail.com> 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 <nj...@gmail.com> 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 <ea...@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
>>>> 
>>> 
>> 
>> 


--
Felix Meschberger | Principal Scientist | Adobe








---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

Re: SCR not binding proxy dependency

[Caspar MacRae <ea...@gmail.com>]

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 <ea...@gmail.com> 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 <nj...@gmail.com> 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 <ea...@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
>> >
>>
>
>

Re: SCR not binding proxy dependency

[Caspar MacRae <ea...@gmail.com>]

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 <nj...@gmail.com> 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 <ea...@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
> >
>

Re: SCR not binding proxy dependency

[Neil Bartlett <nj...@gmail.com>]

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 <ea...@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
>