Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 144783

Summary: Filter specified in ServiceTracker's constructor
Product: [Eclipse Project] Equinox Reporter: Ikuo Yamasaki <yamasaki.ikuo>
Component: FrameworkAssignee: equinox.framework-inbox <equinox.framework-inbox>
Status: RESOLVED INVALID QA Contact:
Severity: enhancement    
Priority: P3 CC: hargrave, Ikuo_Yamasaki, yamasaki.ikuo
Version: 3.2   
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Attachments:
Description Flags
Patch of ServiceTracker of listener filter modification none

Description Ikuo Yamasaki CLA 2006-05-31 17:22:19 EDT 
In case that Filter object is specified in its constructor, the current implementation of ServiceTracker registers a ServiceListener with "null" filter.
In stead, it checks if the reference of ServiceEvent matches the filter in serviceChanged(ServiceEvent) of ServiceListener implementation.

I wonder if the following patch improves performance (I'm not sure how much now) because the filter matching operation will be done by not ServiceListener implementation but FilteredServiceListener of framework  ( before it were delivered to ServiceListener implementation).

Is there any reason for the current implementation ?
Comment 1 Ikuo Yamasaki CLA 2006-05-31 17:24:10 EDT 
Created attachment 43175 [details]
Patch of ServiceTracker of listener filter modification
Comment 2 BJ Hargrave CLA 2006-06-01 09:29:02 EDT 
Yes. There is a reason the code is the way it is. This patch will break the proper operation of the ServiceTracker.

When tracking by class name or service reference id, those values are immutable for a given service registration. When tracking by an arbitraty filter, the service properties which may cause the filter to match are mutable.

For example, when using a ServiceTracker with the filter "(foo=bar)" and ST registers a ServiceListener with the filter "(foo=bar)", if a service is registered with service property foo=bar, then the REGISTERED event will be delivered and the ServiceTracker will track the service. If the service then modifies its properties to change the value of foo to xyz, then the ServiceListener will NOT deliver the MODIFIED event to the ServiceTracker since the filter does not match, foo=xyz and not bar. So the ServiceTracker will not properly untrack the service.

So the ServiceTracker must receive all ServiceEvents when a user specified filter is supplied and test each even to see if the service should be tracked or untracked.
Comment 3 Ikuo Yamasaki CLA 2006-06-01 09:50:06 EDT 
BJ, thank you for your explanation in detail.
I understand the whole.
p.s. I was just thinking of reducing event dispatching operations if possible, because a bunch of registered ServiceListener cause degrade of performance related with service registry.