Scripsit Raymond: > -1% - blueprint (we have a test that fails the build if someone tries to
Personally I would make this -100% :-) I don't regard DS as "magic", because what it does is rather straightforward conceptually and is clearly described in the specification. I only wish I could say the same for all the other annotation-based frameworks in the Java "ecosystem" ... 7 years ago I would have said to concentrate on ServiceTracker and ignore old tutorials which use the low-level interface, and nowadays I would say concentrate on DS and only start messing with ServiceTracker when you really have to. > On Fri, Apr 15, 2016 at 1:34 PM, Alexander Klimetschek > <aklim...@adobe.com> > wrote: >> 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 > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > (@rotty3000) > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> > (@Liferay) > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> > (@OSGiAlliance) > _______________________________________________ > 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
