Thanks - that's perfectly clear.
/jog
On Wed, Jun 3, 2009 at 7:07 PM, Richard S. Hall <[email protected]>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: [email protected]
> For additional commands, e-mail: [email protected]
>
>
