Ok, thank you ! For now I will implement the ordering on my side, inside the listener, as it will be required to work on all frameworks .. If I really need it I will open an RFE and try to provide a patch for that.
Regards Thomas On Wed, Jan 13, 2016 at 4:25 PM Richard S. Hall <he...@ungoverned.org> wrote: > On 1/13/16 03:43 , Thomas Draier wrote: > > Hi, > > It's not about classes (which are correctly loaded by the framework and > > fully available when i get in there), but about custom > > resources/capabilities that I register in the listener. So yes, it fails, > > as the listener cannot load the resources it depends on, which should > have > > been registered earlier by the same listener. As a workaround I could > keep > > track of the bundles inside the listener when they have unresolved > > dependencies, and register them only when the listener has been called on > > all dependencies - but that's quite ugly and risk-prone. I would have > > preferred to rely on the fact that events are sent in order - that would > be > > much more clean and simple. > > Given that the spec doesn't mandate reverse-dependency delivery of > RESOLVED events, I think you have no choice but to not depend on it if > you want to run on any given framework implementation. > > Having said that, I think it would be possible to modify the Felix > framework implement to approximate this ordering by doing something like > taking the wireMap at the end of markResolvedRevisions and rather than > fire the events in order, it could either create a new listed sorted by > dependencies or somehow recursively traverse it following dependencies. > > Feel free to open an RFE (and potentially provided a patch), but again, > even if implemented your bundles could fail on other frameworks. > > -> richard > > > Thomas > > > > On Tue, Jan 12, 2016 at 6:45 PM Richard S. Hall <he...@ungoverned.org> > > wrote: > > > >> On 1/12/16 11:59 , Thomas Draier wrote: > >>> On Tue, Jan 12, 2016 at 5:45 PM Richard S. Hall <he...@ungoverned.org> > >>> wrote: > >>> > >>>> So, are you saying that when you get a resolved event for some > arbitrary > >>>> bundle, you are running into issues because some of its dependencies > are > >>>> not yet treated as if they are resolved? What is the symptom you see? > >>>> > >>> Well, I just did receive the resolved event for the dependencies (Y,Z) > >>> after receiving the event for the bundle having the dependencies (X), > >>> instead of the opposite. Of course, it's not always the case, it > happens > >>> for some bundles only, as the order is random. But yes, all of them are > >>> marked as resolved when I get the first event, and all events will > >>> eventually be sent. > >> What I'm trying to get at is, why is this problematic for you if you get > >> them out of order? Are you try to load a class and it fails, for > >> example. Or does it just make you uncomfortable? > >> > >> -> richard > >> > >>> > >>>> Yes, that's the reverse order, not that this terminology is super > >>>> important. > >>>> > >>> Ok, whatever, just to be sure we were talking of the same order. > >>> > >>> Thomas > >>> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > >> For additional commands, e-mail: users-h...@felix.apache.org > >> > >> -- > > *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. > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > >
