You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Thomas Draier <td...@jahia.com> on 2016/01/12 15:26:14 UTC
Issue with BundleListener/Resolved events
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,
--
*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.
Re: Issue with BundleListener/Resolved events
Posted by Thomas Draier <td...@jahia.com>.
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-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
>
>
Re: Issue with BundleListener/Resolved events
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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-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
Re: Issue with BundleListener/Resolved events
Posted by Thomas Draier <td...@jahia.com>.
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.
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-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.
Re: Issue with BundleListener/Resolved events
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Issue with BundleListener/Resolved events
Posted by Thomas Draier <td...@jahia.com>.
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.
> 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
--
*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.
Re: Issue with BundleListener/Resolved events
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 1/12/16 11:35 , Thomas Draier wrote:
> 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.
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?
> 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).
Yes, that's the reverse order, not that this terminology is super important.
-> richard
> Regards
>
>
>
> On Tue, Jan 12, 2016 at 4:45 PM Richard S. Hall <he...@ungoverned.org>
> 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: 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
Re: Issue with BundleListener/Resolved events
Posted by Thomas Draier <td...@jahia.com>.
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 <he...@ungoverned.org>
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: 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.
Re: Issue with BundleListener/Resolved events
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org