Hi,
I'm trying to get a clear picture of the ServiceTracker. I've looked at
some examples (e.g. http://www.aqute.biz/Snippets/Tracker), but they all
seem rather complicated. I'm especially interested in knowing when I can
assume a service object to exist.
It is clear to me from the specification that a service object is
available (different from null) when the default implementation of
addingService returns. So to avoid constantly calling
myTracker.getService() (and check for null) whenever I want to invoke a
method of the service object, I can derive my own ServiceTracker by
overriding addingService (using the LogService as an example):
@Override
public LogService addingService(ServiceReference<LogService>
reference) {
myLogService = super.addingService(reference);
// Start the thread(s) that refer to (use) myLogService
return myLogService;
}
... and use myLogService until the service becomes unavailable (invalid).
It is less clear to me how to know when the service becomes unavailable.
The specification says:
removedService(ServiceReference,T) - Called whenever a tracked
service is removed from the
ServiceTracker object.
IMHO "is removed" is a bit unspecific (before/after?). However, I found
in the Apache Felix implementation (which isn't a specification, of
course) that removedService is invoked while handling the UNREGISTERING
event:
UNREGISTERING - A service object is in the process of being
unregistered. This event is synchro-
nously delivered before the service object has completed
unregistering. That is, during the deliv-
ery of this event, the service object is still valid.
So I should be on the safe side if I also override removedService:
@Override
public void removedService(ServiceReference<LogService> reference,
LogService service) {
// Interrupt and join the thread(s) that refer to (use) myLogService
myLogService = null;
super.removedService(reference, service);
}
Doing it this way, using myLogService in the thread(s) started in
addingService and stopped in in removeService should be safe, right?
- Michael
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
