Why oh why every time someone asks "help me understand something" everyone seems to be rushing with answering "don't bother, just use X". It's sad. I wish someone could provide the answers so that even those of us who are happy with DS (or whatever else components framework) may learn something new. 15 kwi 2016 22:57 "Paul F Fraser" <pa...@a2zliving.com> napisał(a):
> What we need is a good book :-) > > https://www.indiegogo.com/projects/effective-osgi#/ > > Paul > > On 16/04/2016 5:51 AM, chris.g...@kiffer.be wrote: > >> 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 >> >> > _______________________________________________ > 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
