Hi Neil,
Thanks for the tips.
> With regard to "testing bouncing", there are two sides to this question: the
> component being bounced, and the other components that may be exposed to it
> bouncing.
>
> The component itself should never actually know that it is being, or has
> been,
>> Unless maybe there is a bug in SCR for some edge case (felix version 2.0.2).
>
> This is indeed my suspicion based on what you have described. Have you tried
> using a later SCR implementation, just in case it's a bug that's already been
> fixed?
Thanks, Neil! I updated to 2.0.14, and the
On Sun, Aug 26, 2018 at 1:35 AM David Leangen via osgi-dev <
osgi-dev@mail.osgi.org> wrote:
>
> Hi,
>
> Thank you again for all the great tips in this thread. I have taken the
> time to review concurrency, reread all the blogs, articles, and email
> messages in detail, and I have done a fairly
With regard to "testing bouncing", there are two sides to this question:
the component being bounced, and the other components that may be exposed
to it bouncing.
The component itself should never actually know that it is being, or has
been, bounced. SCR always creates a new instance for each
David,
In my own journey I have had (and still does have) my share of moments
where I'm not sure what's happening. We are still on Equinox/PDE (can't
wait to switch to BND but that will have to wait a bit), and there I have
used the tracing to get insight into the service registry events. With
Hi,
Thank you again for all the great tips in this thread. I have taken the time to
review concurrency, reread all the blogs, articles, and email messages in
detail, and I have done a fairly thorough review of all my code. I have
identified a lot of places where there was potential for
Hi Tim,
>> What is a good way to test for robustness against this phenomenon?
>
> Again, I wish to go on record as saying that bouncing does not mean that
> anything is wrong, nor is it intrinsically bad.
Thanks. Understood. I did not mean to imply anything about “goodness” or
“badness”, but
com
>>>> <mailto:dirk.fa...@de.bosch.com>
>>>>
>>>> Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000;
>>>> Aufsichtsratsvorsitzender: Franz Fehrenbach; Geschäftsführung: Dr. Volkmar
>>>> Denner,
>>>&g
>>> Prof. Dr. Stefan Asenkerschbaumer, Dr. Michael Bolle, Dr. Rolf Bulander,
>>> Dr. Stefan Hartung, Dr. Markus Heyn,
>>> Dr. Dirk Hoheisel, Christoph Kübel, Uwe Raschke, Peter Tyroller
>>>
>>>
>>> Von: osgi-dev-boun...@mail.osgi.org <mailto:osgi-d
.
>> Stefan Hartung, Dr. Markus Heyn,
>> Dr. Dirk Hoheisel, Christoph Kübel, Uwe Raschke, Peter Tyroller
>>
>>
>> Von: osgi-dev-boun...@mail.osgi.org <mailto:osgi-dev-boun...@mail.osgi.org>
>> [mailto:osgi-dev-boun...@mail.osgi.org
>> <mailt
Uwe Raschke, Peter Tyroller
>
>
> Von: osgi-dev-boun...@mail.osgi.org [mailto:osgi-dev-boun...@mail.osgi.org]
> Im Auftrag von Tim Ward via osgi-dev
> Gesendet: Donnerstag, 12. Juli 2018 10:22
> An: Peter Kriens ; OSGi Developer Mail List
>
> Betreff: Re: [osgi-dev] Double c
nnerstag, 12. Juli 2018 10:22
An: Peter Kriens ; OSGi Developer Mail List
Betreff: Re: [osgi-dev] Double config
Hi David,
This is a gift! :-) It means your code is not handling the dynamics correctly
and now you know it!
I’m not sure that there’s quite enough evidence to come to this conclusion
Hi David,
> This is a gift! :-) It means your code is not handling the dynamics correctly
> and now you know it!
I’m not sure that there’s quite enough evidence to come to this conclusion. It
could simply be that everything is working fine with a static policy, and
working the way that DS is
This is a gift! :-) It means your code is not handling the dynamics correctly
and now you know it!
The cause is that that the DS starts the components before the Configurator has
done its work. The easiest solution seems to be to use start levels. If your
code CAN handle the dynamics, then
14 matches
Mail list logo
