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
