Actually, perhaps I was being too theoretical. Bundle events are
delivered on a separate thread, so there are no hard timing guarantees,
but the spec might say somewhere that fired events should take a
snapshot of registered listeners at the time of the event (I think is
says this somewhere...that is how Felix implements it), so it is not
technically possible to receive old events in Felix.
-> richard
Lucas Galfaso wrote:
Hi Richard,
Maybe I am missing something, but I think that C should never see
the events from A and B unless you start C from a different thread
that A and B, and do so at about "the same time" (so you are not
really sure the exact order, but the mail said that A, B and C were
"started in order"). Shouldn't this specific case be covered by "4.6.2
Delivering Events" scenario 1 (even when not using
SynchronizedBundleListeners) ?
As I said, maybe I am missing something.
Regards,
Lucas
On Mon, Jun 16, 2008 at 10:24 AM, Richard S. Hall <[EMAIL PROTECTED]> wrote:
Well, if you are not using SynchronousBundleListener, then it is possible
that C could see events from A and B, because the events are delivered on a
different thread. However, there is no facility for "replaying" events in
the framework...generally speaking, if you miss them, then they are gone.
-> richard
Felix Meschberger wrote:
Hi Saminda,
Am Montag, den 16.06.2008, 02:07 +0530 schrieb Saminda Abeyruwan:
Hi All,
Use case: I have three bundle A, B and C started in order. Is there a
possibility of C bundle to listen to the "event" that A and B already
"started", i.e listen to a delayed event.
No, AFAIK events are devlivered on the event and not backwards in
history -- how far would you want to go back in time given a long
running OSGi application ?
So, your solution for Bundle C is to start listening and gather and
inspect existing bundles.
Regards
Felix
