Hi Richard, Thank you for your answer. I'll try to clarify my needs : I actually have a listener which listen to all bundles resolution. This listener register resources, which have dependencies to other resources from other bundles. Resource registration just cannot happen if dependent resources are not yet available. These dependencies are implemented as bundle capabilities, and so works with bundle resolution. When I receive a "resolved" event on a bundle, I expect that all required capabilities are correctly visible, before I can expose the bundle capabilities. You said, "you receive them in some arbitrary order with respect to dependencies" - that would make me very happy, but from what I see and from what I understand from what you say, that's not the case. Of course if you have dependencies cycles, it's impossible to respect dependency order - in my case, it's not allowed, and so it's always possible to have them in a valid order. Also not sure what you mean by reverse dependency order, I would need simple evaluation order - if X depends on Y and Z, I need to have either (Z,Y,X) or (Y,Z,X). Regards
On Tue, Jan 12, 2016 at 4:45 PM Richard S. Hall <[email protected]> wrote: > 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] > > -- *Thomas Draier* Chief Software Architect & Co-Founder T +33 1 44 79 37 86 8 rue du Sentier | 75002 Paris | France *jahia.com <http://www.jahia.com>* SKYPE | VCARD <http://www.jahia.com/vcard/DraierThomas.vcf> > JOIN OUR COMMUNITY <http://www.jahia.com/> to evaluate, get trained and to discover why Jahia is a leading User Experience Platform (UXP) for Digital Transformation.
