[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] When is DS done loading services?
- From: "Richard S. Hall" <heavy@xxxxxxxxxxxxxx>
- Date: Thu, 04 Sep 2008 11:57:43 -0400
- Delivered-to: email@example.com
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=ungoverned.org; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=bG3GoF8th8PYM95UscCNSbxRRvvuKatMrOD2wD7lTfmuziUokqnhP4AixNic4jgJPuaMGFkzQJbPkiRTktLupISUpTzXjnJtaol3VyHhpaq/K75IYxqdmSprVixrnoZQ;
- User-agent: Thunderbird 220.127.116.11 (X11/20080723)
Danail Nachev wrote:
Richard S. Hall wrote:
I don't think that what I said makes any assumptions about knowing the
exact dependencies. I think my point agrees with what you are saying,
which is that you have to wait for all plugins to start up (including
waiting for their dependencies on each other to be resolved) before you
can plug them into this core component that is going to use them.
Now I see your point (I think:) You are correct, but even without
dynamism, you need some guarantee that if bundle is started, it is
initialized (if all dependencies are available upfront). With
asynchronous DS you don't have this.
If not all dependencies are available, the unsatisfied components will
be registered synchronously with their required services becoming
available (which will happen in some other bundle's start() method in
most cases). The overall result is that after all bundles are started,
all services (which doesn't depend on external factors) are registered.
I think the difficult in this situation, if I understand correctly, is
that the core component does not know in advance which plugins will be
injected, so it doesn't know when it is ready to go. If it takes its
snapshot too early, it might miss some of them. I agree that this is an
issue, but I am not sure what the solution is. One possibility, using an
extender model-like approach, is to have the core component probe
installed plugin bundles to determine which plugins are available to
that it know which ones it has to wait for before continuing.
The framework STARTED event has nothing to do with the readiness of the
application running on top of the framework, it has to do with the state
of the framework. The application must determine when it is ready. How
would the framework ever know if the application is "ready"?
You are right. But the DS asynchronous can make it hard to know when the
application is ready, if the application don't know what it is waiting
for. framework STARTED event seems to be the only valid event, which can
Well, this misappropriates the STARTED event, since you are trying to
construe it to be used for an application-level event.
Senior Software Engineer/Development Tools
ProSyst Labs EOOD
stay in touch with your product.
equinox-dev mailing list