felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Draier <tdra...@jahia.com>
Subject Re: Issue with BundleListener/Resolved events
Date Fri, 15 Jan 2016 12:55:15 GMT
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 <heavy@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 <heavy@ungoverned.org>
> > wrote:
> >
> >> On 1/12/16 11:59 , Thomas Draier wrote:
> >>> On Tue, Jan 12, 2016 at 5:45 PM Richard S. Hall <heavy@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-unsubscribe@felix.apache.org
> >> For additional commands, e-mail: users-help@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-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message