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
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
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
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
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.
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 wrote:
>
> Michael,
>
> I share yo
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
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
nks for the quick response and clarification.
>>>
>>> - Michael
>>>
>>>>
>>>> --
>>>>
>>>> BJ Hargrave
>>>> Senior Technical Staff Member, IBM // office: +1 386 848 1781
>>>> OSGi Fellow and
Given only a single service, your code would work between the one call to addingService and, later, the one call to removedService. But in the presence of multiple services, your code falls apart as described by Tim.
In general, there can be multiple services and their life cycles are fully async
d at the time of the removedService call.
>>>> The point is that the validity of the service "while being added"
>>>> or "after having been removed" cannot be derived from the tense.
>>>> Being notified "after the service has been removed&q
"removedService". Maybe it's already
>>> stated somewhere else, but I failed to find it. Maybe I should be able to
>>> derive it as obvious from the context, but I failed with that as well. (The
>>> documentation of UNREGISTERING is much clearer in that respect.)
&g
>> I failed with that as well. (The documentation of UNREGISTERING is
>> much clearer in that respect.)
>>
>> Thanks for the quick response and clarification.
>>
>> - Michael
>>
>>>
>>> --
>>>
>>> BJ Hargrave
>>> Se
If you need to track a single service and you don't want to use an
extender, you can use the following code instead of the ServiceTracker
(which is not well suited for a single service instance as you saw):
https://github.com/apache/karaf/blob/master/util/src/main/java/org/apache/karaf/util/tracke
----- Original message -----
>> From: Michael Lipp <mailto:m...@mnl.de>
>> Sent by: osgi-dev-boun...@mail.osgi.org
>> <mailto:osgi-dev-boun...@mail.osgi.org>
>> To: osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
>> Cc:
>> Subject: [osgi-d
m.com
>
>
>
> - Original message -----
> From: Michael Lipp
> Sent by: osgi-dev-boun...@mail.osgi.org
> To: osgi-dev@mail.osgi.org
> Cc:
> Subject: [osgi-dev] Clarify usage of ServiceTracker
> Date: Wed, Apr 13, 2016 4:47 PM
>
First, consider using Declarative Services (DS) instead of ServiceTracker. While ServiceTracker is higher level than the plain service APIs in the OSGi framework, DS is a much nicer and higher level model for providing and consuming services. It also now supports field injection, so your service de
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
18 matches
Mail list logo
