felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Issue with BundleListener/Resolved events
Date Tue, 12 Jan 2016 16:44:39 GMT


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 <heavy@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


Mime
View raw message