We would have never accomplished anywhere near the amount of work we've done in the past 2 years without DS.
So it's a big fat +1 for me too. If I had to roughly break down how we use various service handling technologies: 90% - DS 7% - service.tracker.map (our own service mapping API) 2% - org.osgi.util.tracker 1% - apache felix dm (only super complex infra stuff) -1% - blueprint (we have a test that fails the build if someone tries to use this) - Ray 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
