Re: [equinox-dev] When is DS done loading services?

[Danail Nachev <d.nachev@xxxxxxxxxx>]

Danail Nachev
Senior Software Engineer/Development Tools
ProSyst Labs EOOD
-------------------------------------------------
stay in touch with your product.
-------------------------------------------------

Richard S. Hall wrote:
> 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.

Doesn't this mean to duplicate DS work or duplicate information (if you
store the information twice (once for you and once for DS))?

> 
>>> 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
>> be used.
>>   
> 
> Well, this misappropriates the STARTED event, since you are trying to
> construe it to be used for an application-level event.

When the application is the only one inside the framework, framework
STARTED event is, in fact, application-level event because the
application and framework are roughly the same thing - the framework is
the supporting infrastructure of the application. In the other cases I
agree with you (if there is more than one application), but then in the
other cases will don't have the problem with how long to wait for our
dependencies, because the applications are not short-lived and should
deal with the dynamism of OSGi.

> 
> -> richard
> 
>>  
>>> -> richard
>>>
>>>     
>>
>> Danail Nachev
>> Senior Software Engineer/Development Tools
>> ProSyst Labs EOOD
>> -------------------------------------------------
>> stay in touch with your product.
>> -------------------------------------------------
>>
>> _______________________________________________
>> equinox-dev mailing list
>> equinox-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>>   
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
> 
>