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