I think you may be reading more into the spec than what is there.
Technically, a resolve is atomic so all bundles are effectively resolved
at the same time, which means the events occur at the same time, but
since we can only deliver one at a time, then you receive them in some
arbitrary order with respect to dependencies. I don't think the spec
requires events to be delivered in reverse dependency order. Further, it
is fully possible since dependencies can be in the form of [really
large] cycles, thus ordering is not clear.
Why do you care about this ordering?
-> richard
On 1/12/16 09:26 , Thomas Draier wrote:
Hi there,
I have an issue when listening to resolved event - my BundleListener
actually doesn't receive the events in the correct order, where the bundle
resolution really happened.
Let's say we have bundle X , which has a Import-Package: org.aPackage , and
a bundle Y , which Export-Package: org.aPackage . I install both (they goes
to installed state), and then try to start X. X and Y can be resolved, but
Y should be resolved first - however, the events are sent in random order.
More precisely, Felix tries to resolve X by calling
StatefulResolver.resolve(), which then delegates to ResolverImpl.resolve()
- this one will detect that Y needs to be resolved first . Y is then
resolved and added to the wireMap. At the end of StatefulResolver
.resolve(), all resolved events are sent by fireResolvedEvents(wireMap) .
Unfortunately, the order in which the wireMap has been filled is lost, so
the order of bundle resolution - I can receive a resolved event for X
before Y or the opposite, randomly.
Is this something that should/could be fixed ? It should be ok to change
the type of the wireMap to keep ordering of inserts. According to the
specifications, "each handler must receive the events in the same order as
the events were posted" .. here the events are not posted in the same order
as they actually happened .. ?
Regards,
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
