For me that approach has been helpful. I started off a year ago with servicemix and as I learned more I moved down to karaf. I still use karaf for deployments but I also mix in custom build capabilities built on bndtools, enroute components and custom classes. I am still learning about the tools out there for OSGI. I read the code and documentation for the tools they suggest because they are almost all open source and I have found the developers very helpful and willing to answer questions and troubleshoot bugs. I do find that people feel very strongly about what they feel the correct way to do things is but if you work on an open library that takes a different approach I find everyone very helpful and sometimes they are willing to contribute. I think that is part of the reason why there are 5 different good libraries to do service injection and they all bring something different.
On Sat, Apr 16, 2016 at 9:46 AM, Milen Dyankov <milendyan...@gmail.com> wrote: > 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 >
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
