FWIW: As a long time user of DS I can only say it's awesome, and I personally would never use OSGi without it. Never seen any problems with it because of "too much magic" - in fact, it's straightforward.
Cheers, Alex > On 15.04.2016, at 08:41, Neil Bartlett <njbartl...@gmail.com> wrote: > > 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 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 > _______________________________________________ > 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
