You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Jacques-Olivier Goussard <jo...@gmail.com> on 2009/06/03 22:10:16 UTC
Servicetracker constructors
Hi
That's more a question about the OSGi core implementation than about Felix,
but anyway: does anyone know the difference between the
two constructors:
ServiceTracker(BundleContext context, Filter filter,
ServiceTrackerCustomizer customizer)
and
ServiceTracker(BundleContext context, String clazz,
ServiceTrackerCustomizer customizer)
?
I know the first one takes a full filter and the second simply a class, and
I was expecting to simply see in the implementation
this(context, context.createFilter("(objectClass="+clazz), customizer)
for the second one, but that's not the case.
If you use the 1st constructor it seems that the ServiceTracker is actually
registering a listener for ALL services and doing the filtering itself in
the
listener callback whereas the 2nd constructor strictly listens for services
implementing the given class.
That looks weird to me - why not use the
BundleContext.addServiceListener(listener, filter) with a valid filter in
both cases ?
So - is there a performance penalty to use the 1st constructor when you're
actually simply tracking classes ?
Gurus ?
/jog
Re: Servicetracker constructors
Posted by Jacques-Olivier Goussard <jo...@gmail.com>.
Thanks - that's perfectly clear.
/jog
On Wed, Jun 3, 2009 at 7:07 PM, Richard S. Hall <he...@ungoverned.org>wrote:
> The issue is tricky and not related to performance.
>
> The service tracker tracks service objects that match a certain "filter",
> but whether or not it matches can change at run-time if the registering
> bundle modifies the service properties. The tracker needs to know when it
> should stop tracking a service object it may have retrieved, but if a
> service's properties change in such a way that the filter no longer matches,
> the service tracker would not get notified about it.
>
> As a result, the service tracker must get all events and do the matching
> locally to make sure it notices when an existing matching service object
> should no longer be tracked if its service properties change.
>
> In OSGi R4.2, a new event was introduced to make this explicit.
>
> -> richard
>
>
> On 6/3/09 1:10 PM, Jacques-Olivier Goussard wrote:
>
>> Hi
>> That's more a question about the OSGi core implementation than about
>> Felix,
>> but anyway: does anyone know the difference between the
>> two constructors:
>> ServiceTracker(BundleContext context, Filter filter,
>> ServiceTrackerCustomizer customizer)
>> and
>> ServiceTracker(BundleContext context, String clazz,
>> ServiceTrackerCustomizer customizer)
>> ?
>> I know the first one takes a full filter and the second simply a class,
>> and
>> I was expecting to simply see in the implementation
>> this(context, context.createFilter("(objectClass="+clazz), customizer)
>> for the second one, but that's not the case.
>> If you use the 1st constructor it seems that the ServiceTracker is
>> actually
>> registering a listener for ALL services and doing the filtering itself in
>> the
>> listener callback whereas the 2nd constructor strictly listens for
>> services
>> implementing the given class.
>> That looks weird to me - why not use the
>> BundleContext.addServiceListener(listener, filter) with a valid filter in
>> both cases ?
>> So - is there a performance penalty to use the 1st constructor when you're
>> actually simply tracking classes ?
>> Gurus ?
>> /jog
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: Servicetracker constructors
Posted by "Richard S. Hall" <he...@ungoverned.org>.
The issue is tricky and not related to performance.
The service tracker tracks service objects that match a certain
"filter", but whether or not it matches can change at run-time if the
registering bundle modifies the service properties. The tracker needs to
know when it should stop tracking a service object it may have
retrieved, but if a service's properties change in such a way that the
filter no longer matches, the service tracker would not get notified
about it.
As a result, the service tracker must get all events and do the matching
locally to make sure it notices when an existing matching service object
should no longer be tracked if its service properties change.
In OSGi R4.2, a new event was introduced to make this explicit.
-> richard
On 6/3/09 1:10 PM, Jacques-Olivier Goussard wrote:
> Hi
> That's more a question about the OSGi core implementation than about Felix,
> but anyway: does anyone know the difference between the
> two constructors:
> ServiceTracker(BundleContext context, Filter filter,
> ServiceTrackerCustomizer customizer)
> and
> ServiceTracker(BundleContext context, String clazz,
> ServiceTrackerCustomizer customizer)
> ?
> I know the first one takes a full filter and the second simply a class, and
> I was expecting to simply see in the implementation
> this(context, context.createFilter("(objectClass="+clazz), customizer)
> for the second one, but that's not the case.
> If you use the 1st constructor it seems that the ServiceTracker is actually
> registering a listener for ALL services and doing the filtering itself in
> the
> listener callback whereas the 2nd constructor strictly listens for services
> implementing the given class.
> That looks weird to me - why not use the
> BundleContext.addServiceListener(listener, filter) with a valid filter in
> both cases ?
> So - is there a performance penalty to use the 1st constructor when you're
> actually simply tracking classes ?
> Gurus ?
> /jog
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org