felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Caspar MacRae <ear...@gmail.com>
Subject Re: SCR not binding proxy dependency
Date Wed, 10 Apr 2013 08:15:30 GMT
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 <fmeschbe@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 <earcam@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 <njbartlett@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 <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
> >>>>
> >>>
> >>
> >>
>
>
> --
> Felix Meschberger | Principal Scientist | Adobe
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>

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