Michael, I share your aversion to opaque magic, but I'm not entirely in agreement. You seem to be arguing that programmers should have full knowledge of all levels of the stack they are building on. If so, can you explain in detail how, say, the Java garbage collector works?
In fact I suspect you probably can... but my point is that you don't need this knowledge to be a good Java programmer. You only need to know the contract offered by the JVM. Likewise you can be productive with DS without understanding the nitty gritty details of a DS implementation. Neil On 15 Apr 2016 3:19 pm, "Michael Lipp" <m...@mnl.de> wrote: Thanks to everyone. Especially to Timothy for pointing out the problems with the simple approach. I didn't find these problems laid out in any of the examples or tutorials that I came across. I know that a newbie's problems are always a bit "been there, done that" to the experts. But simply using something like DS without further understanding the problems that it solves is a bit like using magic and I don't think that this is what programming should be like. - Michael Am 13.04.2016 um 22:47 schrieb Michael Lipp: 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 listosgi-...@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
