BundleContext.addServiceListener(ServiceListener, String) is a simple
event delivery model. You only get the event if the filter evaluates to
true. I think this is straight forward and well explained.
ServiceTracker has another goal: tracking services that meet the specified
criteria. You want to know when a service meeting your specified criteria
arrives and is added to the tracker and also when a tracked service no
longer meets your criteria and is removed from the tracker. So the
ServiceTracker implementation cannot use
BundleContext.addServiceListener(ServiceListener, String) when tracking
services based upon a user supplied filter since it will never see the
ServiceEvent which leads to the service failing the criteria. So when
constructed with a user supplied Filter, the ServiceTracker impl will
register to see all ServiceEvents and test each event to see if the
service passes or fails the criteria:
else { // user supplied filter
if (filter
.match(reference)) {
track(reference);
}
else {
untrack(reference);
}
This way the service is properly added and removed from the tracker.
I think this text:
"When a service is being added to the ServiceTracker object or when a
tracked
service is modified or removed from the ServiceTracker object, it must
call
addingService, modifiedService or reovedService respectively, on the
ServcieTrackerCustomizer object..."
is consice and accurate. A service is added when it meets the specified
criteria and removed when it no longer meets the criteria.
It you still think there is some spec text changes needed, can you suggest
the wording you would like to see and where you think it should be placed?
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[EMAIL PROTECTED]
office: +1 386 848 1781
mobile: +1 386 848 3788
Niclas Hedhman <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
02/14/2007 11:08 PM
Please respond to
OSGi Developer Mail List <[email protected]>
To
[email protected]
cc
Subject
[osgi-dev] ServiceTracking unclarity
Spec Experts;
The specification for BundleContext.addServiceListener says that if we
change
the service property, the whole lifecycle will NOT be seen by the
listener.
I can't find the clarity in the ServiceTracker specification. It says;
"When a service is being added to the ServiceTracker object or when a
tracked
service is modified or removed from the ServiceTracker object, it must
call
addingService, modifiedService or reovedService respectively, on the
ServcieTrackerCustomizer object..."
However, it is unclear what "added to..." refers to, and what the real
intent
really is.
I provide a tracking filter to the ServiceTracker that uses service
properties; (&(objectClass=org.hedhman.MyService)(habba=abc))
IMHO, if I change the property "habba" of myService from "def" to "abc"
the
ServiceTrackerCustomizer.addedService() should[1] be called for the above
tracker. Likewise, if the filter of the tracking 'looses' the service,
then
removedService() should be called. I.e. modifiedService would only be
called
if service properties are changed, but the filter is still evaluating
true.
This is significantly different from what is descibed in the
BundleContext.addServiceListener, and may be considered both
"incompatible"
as well as "complicated", but it makes sense for the user.
In either case, I think the documentation should be complemented with a
diagram of the full cycle.
Cheers
Niclas
[1] I have actually not tried this yet, but it is part of upcoming work
this
week. Looking at the ServiceTracker source, I get the impression that only
the services that initially match the filter will be considered at all.
_______________________________________________
OSGi Developer Mail List
[email protected]
http://www2.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
http://www2.osgi.org/mailman/listinfo/osgi-dev
