[equinox-dev] Re: GWT+Equinox

[Gunnar Wagenknecht]

Hi Ricardo,

Ricardo Giacomin schrieb:
> I tried to follow the directions from wiki page
> http://wiki.eclipse.org/index.php/Google_Web_Toolkit_and_Equinox with no
> success. 

I've updated the wiki page with the GWT Planet Eclipse Demo that I gave
at EclipseCon 2007+2008. You might want to give it a try.

http://wiki.eclipse.org/Google_Web_Toolkit_and_Equinox#GWT_Based_Planet_Eclipse_Demo

It comes with ready-to-use GWT bundles (current version is GWT 1.5.0)
and contains a fix for GWT issue 1888. This way you don't need to use
buddy classloading.

-Gunnar

-- 
Gunnar Wagenknecht
[EMAIL PROTECTED]
http://wagenknecht.org/

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] Project meta data is out of date for rt.equinox

[portal on behalf of emo]

Jeff, Thomas,
Projects are required to keep meta data up to date using the MyFoundation
Portal (http://portal.eclipse.org/).  The following problems were found
with this project's meta-data:

* Project home page does not have an "About This Project" or "Information
about " item at the top of the left menu. Projects are required to
provide that standard link on their home page (see
http://www.eclipse.org/projects/standard-link-on-home-page.php).

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

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

[BJ Hargrave]

> I totally agree. This is what I actually wanted in the very beginning of 

> this thread.

OK, but I certainly did not understand that at the beginning :-)

-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[EMAIL PROTECTED]

office: +1 386 848 1781
mobile: +1 386 848 3788
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

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

[Stoyan Boshev]

BJ Hargrave wrote:


 > > I feel that changing DS to perform service registration synchronous 
with
 > > bundle activation will likely result in deadlocks when there are 
complex

 > > service dependency graphs.
 >
 > This won't be any different from what is done now manually. The
 > potential for deadlocks are there regardless of DS.
 >

Perhaps, but at least we are not building it into the DS spec or the DS 
impl!


 > >
 > > One possible way to deal with this is through the use of component
 > > enablement. Using the original example of service A depending upon some
 > > number of service B, if you can know when all the service Bs are
 > > available, one can write a component with a dynamic dependency on B.
 > > When all the Bs are available then enable the component providing
 > > service A (which are declared disabled in its description). The 
trick is

 > > of course to be able to know when all the service Bs are available such
 > > that we are ready to enable serviceA.
 >
 > And we are back to the core problem: we cannot be sure when all service
 > Bs are available.

How can you ever be sure? :-) Unless there is some definition of the 
expected set of Bs, it is just random.


 > In code which doesn't use DS, start() method will
 > serve as a boundary for the service changes - satisfied services will be
 > registered while the bundle is starting and any services which becomes
 > satisfied will be registered synchronously (the latter is the current
 > behavior of DS).

This makes the assumption that bundle will always register their B 
during BundleActivator execution. I think this is a fairly tall 
assumption. What if a bundle's B depends upon something which is not yet 
available? It is very bad form to block the BundleActivator. So such a 
bundle, if well behaved, would have to return from the BundleActivator 
w/o having registered B and delay registering B until the dependency is 
met some time later.


 >  After all the bundles are activated, we can be sure
 > that all services which doesn't depend on external factors will be
 > available and the system can be considered ready.
 >

You assume ("all services which doesn't depend on external factors") 
that all B's have no dependencies and can be registered at will. That is 
a pretty big assumption.


Perhaps one thing a DS impl could do, is to register all services for 
which all dependencies are currently met synchronously during bundle 
activation. All other services would have to handled asynchronously. 
This splits the DS work between work that can be quickly done during 
bundle activation and work that will take time which is done after 
bundle activation. I don't think any change to the DS spec is needed to 
allow this behavior.


I totally agree. This is what I actually wanted in the very beginning of 
this thread.





--

*BJ Hargrave*
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the _OSGi Alliance_ _
[EMAIL PROTECTED]   

office: +1 386 848 1781
mobile: +1 386 848 3788





___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev


--
-
dipl. eng. Stoyan Boshev . Department manager
ProSyst Labs EOOD
1606 Sofia, Bulgaria . 48 Vladajska Str.
Tel. +359 2 953 05 88; Fax +359 2 953 26 17
Mobile: +359 88 898 29 17
http://www.prosyst.com . [EMAIL PROTECTED]
-
stay in touch with your product
-
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

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

[Richard S. Hall]

Danail Nachev wrote:

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


Well, it isn't duplicating the work of DS, because DS doesn't do this, 
but it may duplicate some information.



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.
  


You are free to think this, but in my view it is incorrect. The STARTED 
event only indicates that the framework has finished performing its 
startup tasks, nothing more and nothing less.


-> richard

  

-> richard


 
  

-> richard




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

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
  
  

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev




___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
  

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

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

[BJ Hargrave]

> > I feel that changing DS to perform service registration synchronous 
with
> > bundle activation will likely result in deadlocks when there are 
complex
> > service dependency graphs.
> 
> This won't be any different from what is done now manually. The
> potential for deadlocks are there regardless of DS.
> 

Perhaps, but at least we are not building it into the DS spec or the DS 
impl!

> > 
> > One possible way to deal with this is through the use of component
> > enablement. Using the original example of service A depending upon 
some
> > number of service B, if you can know when all the service Bs are
> > available, one can write a component with a dynamic dependency on B.
> > When all the Bs are available then enable the component providing
> > service A (which are declared disabled in its description). The trick 
is
> > of course to be able to know when all the service Bs are available 
such
> > that we are ready to enable serviceA.
> 
> And we are back to the core problem: we cannot be sure when all service
> Bs are available.

How can you ever be sure? :-) Unless there is some definition of the 
expected set of Bs, it is just random.

> In code which doesn't use DS, start() method will
> serve as a boundary for the service changes - satisfied services will be
> registered while the bundle is starting and any services which becomes
> satisfied will be registered synchronously (the latter is the current
> behavior of DS).

This makes the assumption that bundle will always register their B during 
BundleActivator execution. I think this is a fairly tall assumption. What 
if a bundle's B depends upon something which is not yet available? It is 
very bad form to block the BundleActivator. So such a bundle, if well 
behaved, would have to return from the BundleActivator w/o having 
registered B and delay registering B until the dependency is met some time 
later.

>  After all the bundles are activated, we can be sure
> that all services which doesn't depend on external factors will be
> available and the system can be considered ready.
> 

You assume ("all services which doesn't depend on external factors") that 
all B's have no dependencies and can be registered at will. That is a 
pretty big assumption.

Perhaps one thing a DS impl could do, is to register all services for 
which all dependencies are currently met synchronously during bundle 
activation. All other services would have to handled asynchronously. This 
splits the DS work between work that can be quickly done during bundle 
activation and work that will take time which is done after bundle 
activation. I don't think any change to the DS spec is needed to allow 
this behavior.

-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[EMAIL PROTECTED]

office: +1 386 848 1781
mobile: +1 386 848 3788
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

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

[Danail Nachev]

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@eclipse.org
>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>>   
> ___
> equinox-dev mailing list
> equinox-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
> 
> 
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

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

[Richard S. Hall]

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
be used.
  


Well, this misappropriates the STARTED event, since you are trying to 
construe it to be used for an application-level event.


-> richard

  

-> richard




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

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
  

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

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

[Danail Nachev]

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.

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

> 
> -> richard
> 

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

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

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

[Danail Nachev]

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

BJ Hargrave wrote:
> 
>> As to the question of DS, let's not forget that it is just an
>> instrument. From what I understand, its goal is to help developers
>> work around OSGi complexities. If it does not help, it needs to be fixed.
> 
> I am all for fixing DS if it is flawed. But your argument against using
> startlevel can be applied to anything which attempts to fix some
> ordering. The difficult point is that bundles can be interdependent.
> They and services are dynamic. You can attempt to hide the dynamism
> through the use of static policies in DS but that only goes so far.
> Using DS, one can fairly easily deal with service dynamism. There are
> bind/unbind methods which are called when services come and go so the
> bundle can be notified of changes to the set of services.
> 
> I feel that changing DS to perform service registration synchronous with
> bundle activation will likely result in deadlocks when there are complex
> service dependency graphs.

This won't be any different from what is done now manually. The
potential for deadlocks are there regardless of DS.

> 
> One possible way to deal with this is through the use of component
> enablement. Using the original example of service A depending upon some
> number of service B, if you can know when all the service Bs are
> available, one can write a component with a dynamic dependency on B.
> When all the Bs are available then enable the component providing
> service A (which are declared disabled in its description). The trick is
> of course to be able to know when all the service Bs are available such
> that we are ready to enable serviceA.

And we are back to the core problem: we cannot be sure when all service
Bs are available. In code which doesn't use DS, start() method will
serve as a boundary for the service changes - satisfied services will be
registered while the bundle is starting and any services which becomes
satisfied will be registered synchronously (the latter is the current
behavior of DS). After all the bundles are activated, we can be sure
that all services which doesn't depend on external factors will be
available and the system can be considered ready.

> 
> 
> -- 
> 
> *BJ Hargrave*
> Senior Technical Staff Member, IBM
> OSGi Fellow and CTO of the _OSGi Alliance_ _
> [EMAIL PROTECTED]   
> 
> office: +1 386 848 1781
> mobile: +1 386 848 3788
> 
> 
> 
> 
> 
> ___
> equinox-dev mailing list
> equinox-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

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

[Richard S. Hall]

Danail Nachev wrote:

Richard S. Hall wrote:
  

Danail Nachev wrote:


I'm not sure what is the application being discussed here, but here is a
use case:

An RCP application is being built, which is headless and when launched
does some processing and then exits (Update manager refreshes the
installation?). This application supports plugins. So, when the
application is launched it should get reference to all plugins and use
them do its thing. I don't think it is possible to deal with the
dynamics of OSGi registry in this case - the application needs to know
the available plugins upfront (or it can use the extension registry).
  
  

Did you say why you cannot install your plugins in a lower start level?



It seems that there is much better workaround for the Otto problem:
using a component in a bundle with the highest start level will cause
the DS to process this component last. Perhaps, everybody else has this
in mind from the beginning, but I failed to see it:) Note that this
workaround requires:
* components to be processed in the order they receive
* when a component is activated, all dependent components are processed
synchronously

If those two conditions are not met, the workaround won't work. I don't
remember such requirements in the specification, so it is implementation
dependent.

  

Such usage of OSGi may not be very natural (an application which doesn't
change while running), but OSGi provides other advantages beside the
dynamic environment.

Another thing is how bundles are developed usually: if a bundle provides
services w/o dependencies, they are registered in the Activator's start
method. If a bundle provides services with dependencies upon another
services, the bundle opens a tracker and register the service when all
its dependencies are satisfied. Because the tracker is opened in the
start() method, the service is registered immediately (in the same
start() method call). The current DS operation is similar to: when the
bundle is started, it spawns a thread which registers what it is needed.
This doesn't feel natural.
  
  

I think these are the issue you always have when you have a bunch of
things that need to be started and there are dependencies among them. If
your assumption is that none of your plugins depend on each other, then
I understand why it appears like this is easy situation to resolve for
your core component since it just needs to be injected with all plugins.
However, if there are dependencies among plugins, even if there is no
dynamism, then you still have to wait for everything to come up to
handle the ordering of dependencies before you can continue.



It seems that you incorrectly assumes that the exact dependencies are
known. The case might be that there are optional things, but
unfortunately you need to snapshot the available dependencies and start
doing what you do. It is of no use if the service is available later (at
least in the case I describe), because you cannot just plug them in the
process (they missed some steps of the processing or sth.).
  


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.



Another effect of the synchronous processing: it will clear up the
meaning of framework started event: With DS handling services
asynchronously, framework started has no meaning, because the framework
isn't ready when the event is delivered (same with start level changes)
- DS is still registering services.
  
  

Well, the framework is ready. The services aren't.



Overall, the system is not ready. I'm starting to question what is the
purpose of the framework started event. Knowing that all bundles are
activated is of no use, if they register their services afterwards (of
course, there are cases which are against this, but they aren't many).
  


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


-> richard


OSGi supports dynamic changes, but I think it should be left to the
clients to decide whether they need it. Using a subset of the OSGi
features is perfectly OK, IMHO.
  
  

Agreed.

-> richard



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

Cortez, Otto wrote:
 
  

Is that true of all extension of the
org.eclipse.core.runtime.applications extension point, that they don’t
start until the platform has been initialized?  Even w

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

[Danail Nachev]

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

Richard S. Hall wrote:
> Danail Nachev wrote:
>> I'm not sure what is the application being discussed here, but here is a
>> use case:
>>
>> An RCP application is being built, which is headless and when launched
>> does some processing and then exits (Update manager refreshes the
>> installation?). This application supports plugins. So, when the
>> application is launched it should get reference to all plugins and use
>> them do its thing. I don't think it is possible to deal with the
>> dynamics of OSGi registry in this case - the application needs to know
>> the available plugins upfront (or it can use the extension registry).
>>   
> 
> Did you say why you cannot install your plugins in a lower start level?

It seems that there is much better workaround for the Otto problem:
using a component in a bundle with the highest start level will cause
the DS to process this component last. Perhaps, everybody else has this
in mind from the beginning, but I failed to see it:) Note that this
workaround requires:
* components to be processed in the order they receive
* when a component is activated, all dependent components are processed
synchronously

If those two conditions are not met, the workaround won't work. I don't
remember such requirements in the specification, so it is implementation
dependent.

> 
>> Such usage of OSGi may not be very natural (an application which doesn't
>> change while running), but OSGi provides other advantages beside the
>> dynamic environment.
>>
>> Another thing is how bundles are developed usually: if a bundle provides
>> services w/o dependencies, they are registered in the Activator's start
>> method. If a bundle provides services with dependencies upon another
>> services, the bundle opens a tracker and register the service when all
>> its dependencies are satisfied. Because the tracker is opened in the
>> start() method, the service is registered immediately (in the same
>> start() method call). The current DS operation is similar to: when the
>> bundle is started, it spawns a thread which registers what it is needed.
>> This doesn't feel natural.
>>   
> 
> I think these are the issue you always have when you have a bunch of
> things that need to be started and there are dependencies among them. If
> your assumption is that none of your plugins depend on each other, then
> I understand why it appears like this is easy situation to resolve for
> your core component since it just needs to be injected with all plugins.
> However, if there are dependencies among plugins, even if there is no
> dynamism, then you still have to wait for everything to come up to
> handle the ordering of dependencies before you can continue.

It seems that you incorrectly assumes that the exact dependencies are
known. The case might be that there are optional things, but
unfortunately you need to snapshot the available dependencies and start
doing what you do. It is of no use if the service is available later (at
least in the case I describe), because you cannot just plug them in the
process (they missed some steps of the processing or sth.).

> 
>> Another effect of the synchronous processing: it will clear up the
>> meaning of framework started event: With DS handling services
>> asynchronously, framework started has no meaning, because the framework
>> isn't ready when the event is delivered (same with start level changes)
>> - DS is still registering services.
>>   
> 
> Well, the framework is ready. The services aren't.

Overall, the system is not ready. I'm starting to question what is the
purpose of the framework started event. Knowing that all bundles are
activated is of no use, if they register their services afterwards (of
course, there are cases which are against this, but they aren't many).

> 
>> OSGi supports dynamic changes, but I think it should be left to the
>> clients to decide whether they need it. Using a subset of the OSGi
>> features is perfectly OK, IMHO.
>>   
> 
> Agreed.
> 
> -> richard
> 
>> -- 
>> Danail Nachev
>> Senior Software Engineer/Development Tools
>> ProSyst Labs EOOD
>> -
>> stay in touch with your product.
>> -
>>
>> Cortez, Otto wrote:
>>  
>>> Is that true of all extension of the
>>> org.eclipse.core.runtime.applications extension point, that they don’t
>>> start until the platform has been initialized?  Even when they run in
>>> any thread and not just the main?
>>>
>>>  
>>>
>>> I would be happy enough to be able to say: if you declare your services
>>> in this way, we will wait for those to be initialized before we start,
>>> otherwise we won’t guarantee your service will be available.  I was
>>> hopping to be able to do that through DS, so waiting for th

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

[BJ Hargrave]

> As to the question of DS, let's not forget that it is just an 
> instrument. From what I understand, its goal is to help developers 
> work around OSGi complexities. If it does not help, it needs to be 
fixed. 

I am all for fixing DS if it is flawed. But your argument against using 
startlevel can be applied to anything which attempts to fix some ordering. 
The difficult point is that bundles can be interdependent. They and 
services are dynamic. You can attempt to hide the dynamism through the use 
of static policies in DS but that only goes so far. Using DS, one can 
fairly easily deal with service dynamism. There are bind/unbind methods 
which are called when services come and go so the bundle can be notified 
of changes to the set of services.

I feel that changing DS to perform service registration synchronous with 
bundle activation will likely result in deadlocks when there are complex 
service dependency graphs. 

One possible way to deal with this is through the use of component 
enablement. Using the original example of service A depending upon some 
number of service B, if you can know when all the service Bs are 
available, one can write a component with a dynamic dependency on B. When 
all the Bs are available then enable the component providing service A 
(which are declared disabled in its description). The trick is of course 
to be able to know when all the service Bs are available such that we are 
ready to enable serviceA.


-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[EMAIL PROTECTED]

office: +1 386 848 1781
mobile: +1 386 848 3788
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

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

[Richard S. Hall]

Oleg Besedin wrote:


> Did you say why you cannot install your plugins in a lower start level?

IMHO, reliance on a start levels should be avoided:

- start levels don't scale if you are putting together an application 
that combines features created by separate development teams (i.e., 
Feature A has startup sequence, Feature B has startup sequence, they 
might be fine if mixed together -  or not)


- start levels create rather brittle bootstrap sequences that take an 
effort to maintain through releases (from the experience of Equinox)


Agreed. But we are talking about a specific use case here, not in general.

As to the question of DS, let's not forget that it is just an 
instrument. From what I understand, its goal is to help developers 
work around OSGi complexities. If it does not help, it needs to be fixed.


Yes, but the main complexity it is trying to simplify is handling 
dynamism. It doesn't attempt to eliminate dynamism, which is what is 
being asked.


-> richard



Thanks,
Oleg


___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
  

___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

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

[Oleg Besedin]

> Did you say why you cannot install your plugins in a lower start level?

IMHO, reliance on a start levels should be avoided:

- start levels don't scale if you are putting together an application that 
combines features created by separate development teams (i.e., Feature A 
has startup sequence, Feature B has startup sequence, they might be fine 
if mixed together -  or not)

- start levels create rather brittle bootstrap sequences that take an 
effort to maintain through releases (from the experience of Equinox)

As to the question of DS, let's not forget that it is just an instrument. 
>From what I understand, its goal is to help developers work around OSGi 
complexities. If it does not help, it needs to be fixed.

Thanks,
Oleg
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

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

[Chris Hopkins]

One approach that I've thought about with the OSGi work we are doing is
to manually handle the installation and starting of bundles. One might
envision having a known directory structure like:

core
defaults
addons

Your application would start up normally within the OSGi environment.
Then, your app would install and start the bundles located in the core
directory, wait for those to start and then proceed to the defaults and
addons directories.

This doesn't *really* help your situation as my understanding is that
you can get a notification of the bundle start but that still does not
guarantee that all the services provided by that bundle are available.
It does allow you for some measure of bookkeeping because you manage the
installation/start of the bundles manually instead of leaving it up to
the run levels.

Whether or not this is a good use of OSGi is certainly up for debate. :)

  - Chris


 
 
 
 
THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. IT 
MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM 
DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your 
use of this message for any purpose is strictly prohibited. If you have 
received this communication in error, please delete the message and notify the 
sender so that we may correct our records.
 
-Original Message-
 
 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Danail Nachev
Sent: Thursday, September 04, 2008 3:23 AM
To: Equinox development mailing list
Subject: Re: [equinox-dev] When is DS done loading services?

I'm not sure what is the application being discussed here, but here is a
use case:

An RCP application is being built, which is headless and when launched
does some processing and then exits (Update manager refreshes the
installation?). This application supports plugins. So, when the
application is launched it should get reference to all plugins and use
them do its thing. I don't think it is possible to deal with the
dynamics of OSGi registry in this case - the application needs to know
the available plugins upfront (or it can use the extension registry).

Such usage of OSGi may not be very natural (an application which doesn't
change while running), but OSGi provides other advantages beside the
dynamic environment.

Another thing is how bundles are developed usually: if a bundle provides
services w/o dependencies, they are registered in the Activator's start
method. If a bundle provides services with dependencies upon another
services, the bundle opens a tracker and register the service when all
its dependencies are satisfied. Because the tracker is opened in the
start() method, the service is registered immediately (in the same
start() method call). The current DS operation is similar to: when the
bundle is started, it spawns a thread which registers what it is needed.
This doesn't feel natural.

Another effect of the synchronous processing: it will clear up the
meaning of framework started event: With DS handling services
asynchronously, framework started has no meaning, because the framework
isn't ready when the event is delivered (same with start level changes)
- DS is still registering services.

OSGi supports dynamic changes, but I think it should be left to the
clients to decide whether they need it. Using a subset of the OSGi
features is perfectly OK, IMHO.

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

Cortez, Otto wrote:
> Is that true of all extension of the
> org.eclipse.core.runtime.applications extension point, that they don't
> start until the platform has been initialized?  Even when they run in
> any thread and not just the main?
> 
>  
> 
> I would be happy enough to be able to say: if you declare your
services
> in this way, we will wait for those to be initialized before we start,
> otherwise we won't guarantee your service will be available.  I was
> hopping to be able to do that through DS, so waiting for the DS thread
> to stop seems fine, although it would be nice to have a more formal
way
> to do this, through public API.
> 
>  
> 
> In our application, we don't expect bundles to be started and stopped
> dynamically (at least not too often), so we are really only worried
> about knowing what services there are at the initial startup.
> 
>  
> 
> I was trying to figure out a good way to safeguard against the
dynamism
> of the services.  I don't think there is an issue with the services
> which require 0..1 or 1..1 instances of another service, but I don't
> know what to do about the services which require 0..n and 1..n because
> you don't really know how many more services there might be without
> doing what DS seems to already do, look through the manifests and find
> the declared services.  I suppose you could also wait for th

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

[Richard S. Hall]

Danail Nachev wrote:

I'm not sure what is the application being discussed here, but here is a
use case:

An RCP application is being built, which is headless and when launched
does some processing and then exits (Update manager refreshes the
installation?). This application supports plugins. So, when the
application is launched it should get reference to all plugins and use
them do its thing. I don't think it is possible to deal with the
dynamics of OSGi registry in this case - the application needs to know
the available plugins upfront (or it can use the extension registry).
  


Did you say why you cannot install your plugins in a lower start level?


Such usage of OSGi may not be very natural (an application which doesn't
change while running), but OSGi provides other advantages beside the
dynamic environment.

Another thing is how bundles are developed usually: if a bundle provides
services w/o dependencies, they are registered in the Activator's start
method. If a bundle provides services with dependencies upon another
services, the bundle opens a tracker and register the service when all
its dependencies are satisfied. Because the tracker is opened in the
start() method, the service is registered immediately (in the same
start() method call). The current DS operation is similar to: when the
bundle is started, it spawns a thread which registers what it is needed.
This doesn't feel natural.
  


I think these are the issue you always have when you have a bunch of 
things that need to be started and there are dependencies among them. If 
your assumption is that none of your plugins depend on each other, then 
I understand why it appears like this is easy situation to resolve for 
your core component since it just needs to be injected with all plugins. 
However, if there are dependencies among plugins, even if there is no 
dynamism, then you still have to wait for everything to come up to 
handle the ordering of dependencies before you can continue.



Another effect of the synchronous processing: it will clear up the
meaning of framework started event: With DS handling services
asynchronously, framework started has no meaning, because the framework
isn't ready when the event is delivered (same with start level changes)
- DS is still registering services.
  


Well, the framework is ready. The services aren't.


OSGi supports dynamic changes, but I think it should be left to the
clients to decide whether they need it. Using a subset of the OSGi
features is perfectly OK, IMHO.
  


Agreed.

-> richard


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

Cortez, Otto wrote:
  

Is that true of all extension of the
org.eclipse.core.runtime.applications extension point, that they don’t
start until the platform has been initialized?  Even when they run in
any thread and not just the main?

 


I would be happy enough to be able to say: if you declare your services
in this way, we will wait for those to be initialized before we start,
otherwise we won’t guarantee your service will be available.  I was
hopping to be able to do that through DS, so waiting for the DS thread
to stop seems fine, although it would be nice to have a more formal way
to do this, through public API.

 


In our application, we don’t expect bundles to be started and stopped
dynamically (at least not too often), so we are really only worried
about knowing what services there are at the initial startup.

 


I was trying to figure out a good way to safeguard against the dynamism
of the services.  I don’t think there is an issue with the services
which require 0..1 or 1..1 instances of another service, but I don’t
know what to do about the services which require 0..n and 1..n because
you don’t really know how many more services there might be without
doing what DS seems to already do, look through the manifests and find
the declared services.  I suppose you could also wait for the platform
to stop starting bundles, but then DS could still be running so I’d
still need a way to know when it was done.

 


Thanks,
Otto

 




*From:* [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] *On Behalf Of *Thomas Watson
*Sent:* Wednesday, September 03, 2008 1:30 PM
*To:* Equinox development mailing list
*Subject:* RE: [equinox-dev] When is DS done loading services?

 


I think part of the problem here is the term "application". In this case
we are talking about an RCP application which is defined as an Eclipse
extension to the org.eclipse.core.runtime.applications extension point.
When launching Eclipse the default application is started after the
platform has been initialized and the start-level has reached the final
state.

RCP applications have historically depended on the platform to be "fully
booted" and ready before thei

Re: [equinox-dev] Starting equinox framework in program

[Thomas Watson]

In the Galileo release (3.5), Equinox is implementing the next version of
the OSGi R4.2 specification.  One of the new features in OSGi R4.2 is the
ability to boot another framework instance.  See
https://bugs.eclipse.org/bugs/show_bug.cgi?id=23 for more information.

You should be able to do something like this

Properties configuration = new Properties();
configuration.put(SystemBundle.STORAGE, "/path/to/my/configuration");
SystemBundle equinox = new Equinox();
equinox.init(configuration);
BundleContext systemContext = equinox.getBundleContext();
// manage your bundles here

// now start the framework
equinox.start();


Note that the for RFC 132 is still early and evolving.  It would be good to
get others experience with using this new feature.  If you have any issues
or questions about using this feature please respond in the bug report
https://bugs.eclipse.org/bugs/show_bug.cgi?id=23


Tom





   
  From:   "林恺" <[EMAIL PROTECTED]>  


   
  To: "Equinox development mailing list"   
   

   
  Date:   09/04/2008 06:04 AM   
   

   
  Subject:Re: [equinox-dev] Starting equinox framework in program   
   

   





Meng,
   Thanks again. The reason why I did not install my plug-in in my
application is: my application is not an RCP-based application, most of
them might be headless application or web UI application. I developed this
plug-in because I was building an IDE to support the development and
monitor Equinox-based application, and my monitor plug-in is part of this
IDE.
   I have thought about using Runtime.exec() to start my another Equinox
framework, but how can I get BundleContext using this method?

Link

2008/9/4 Meng Xin Zhu <[EMAIL PROTECTED]>
  Why not install those plug-ins in your application? Then your plug-in can
  be in charge of monitoring and manging those plug-ins. The
  EclipseStarter.startup you called in your plug-in that is the main
  function of your app. You can easily find that Equinox prevents the
  framework running again if it's running in the source code of
  EclipseStarter. If you want to start another Equinox framework, try
  Runtime.exec.
  ___
  equinox-dev mailing list
  equinox-dev@eclipse.org
  https://dev.eclipse.org/mailman/listinfo/equinox-dev

<><>___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Starting equinox framework in program

[林恺]

Meng,   Thanks again. The reason why I did not install my plug-in in my
application is: my application is not an RCP-based application, most of them
might be headless application or web UI application. I developed this
plug-in because I was building an IDE to support the development and monitor
Equinox-based application, and my monitor plug-in is part of this IDE.
   I have thought about using Runtime.exec() to start my another Equinox
framework, but how can I get BundleContext using this method?

Link

2008/9/4 Meng Xin Zhu <[EMAIL PROTECTED]>

> Why not install those plug-ins in your application? Then your plug-in can
> be in charge of monitoring and manging those plug-ins. The
> EclipseStarter.startup you called in your plug-in that is the main function
> of your app. You can easily find that Equinox prevents the framework running
> again if it's running in the source code of EclipseStarter. If you want to
> start another Equinox framework, try Runtime.exec.
>
>
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Starting equinox framework in program

[Meng Xin Zhu]

Why not install those plug-ins in your application? Then your plug-in can
be in charge of monitoring and manging those plug-ins. The
EclipseStarter.startup you called in your plug-in that is the main function
of your app. You can easily find that Equinox prevents the framework
running again if it's running in the source code of EclipseStarter. If you
want to start another Equinox framework, try Runtime.exec.




|>
| From:  |
|>
  
>--|
  |"林恺" <[EMAIL PROTECTED]> 
  |
  
>--|
|>
| To:|
|>
  
>--|
  |"Equinox development mailing list"  
 |
  
>--|
|>
| Date:  |
|>
  
>--|
  |2008-09-04 11:54 
 |
  
>--|
|>
| Subject:   |
|>
  
>--|
  |Re: [equinox-dev] Starting equinox framework in program  
 |
  
>--|
|>
| Sent by:   |
|>
  
>--|
  |[EMAIL PROTECTED]
   |
  
>--|





Meng,
  Thanks for your reply.
   Yes, my plug-in is an UI Eclipse plugin. And it's true that Equinox
framework will be start firstly when Eclipse launched. But the problem is
the Equinox framework I want to start is not the framework of Eclipse
platform where my plug-in is install in. The Equinox framework I want to
start is another framework (application), and all the bundle is in a
folder.
  I want to start another Equinox framework through my plug-in, and install
all the bundles of the application through my plug-in, then I can control
and monitor the bundles on the Equinox framework. For that my plug-in is a
Bundle Monitor tool to control another Equinox-based application.


2008/9/4 Meng Xin Zhu <[EMAIL PROTECTED]>
  As you said your application is an Eclipse plug-in, I assume it's RCP
  application whether it has UI or not. Equiiox(OSGi) framework would be
  started firstly when your application launch, then your plug-in can
  obtain BundleContext in its bundle activator. Don't need explicitly call
  EclipseStarter.startup to launch OSGi framework.



___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev






<><>___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

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

[Danail Nachev]

I'm not sure what is the application being discussed here, but here is a
use case:

An RCP application is being built, which is headless and when launched
does some processing and then exits (Update manager refreshes the
installation?). This application supports plugins. So, when the
application is launched it should get reference to all plugins and use
them do its thing. I don't think it is possible to deal with the
dynamics of OSGi registry in this case - the application needs to know
the available plugins upfront (or it can use the extension registry).

Such usage of OSGi may not be very natural (an application which doesn't
change while running), but OSGi provides other advantages beside the
dynamic environment.

Another thing is how bundles are developed usually: if a bundle provides
services w/o dependencies, they are registered in the Activator's start
method. If a bundle provides services with dependencies upon another
services, the bundle opens a tracker and register the service when all
its dependencies are satisfied. Because the tracker is opened in the
start() method, the service is registered immediately (in the same
start() method call). The current DS operation is similar to: when the
bundle is started, it spawns a thread which registers what it is needed.
This doesn't feel natural.

Another effect of the synchronous processing: it will clear up the
meaning of framework started event: With DS handling services
asynchronously, framework started has no meaning, because the framework
isn't ready when the event is delivered (same with start level changes)
- DS is still registering services.

OSGi supports dynamic changes, but I think it should be left to the
clients to decide whether they need it. Using a subset of the OSGi
features is perfectly OK, IMHO.

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

Cortez, Otto wrote:
> Is that true of all extension of the
> org.eclipse.core.runtime.applications extension point, that they don’t
> start until the platform has been initialized?  Even when they run in
> any thread and not just the main?
> 
>  
> 
> I would be happy enough to be able to say: if you declare your services
> in this way, we will wait for those to be initialized before we start,
> otherwise we won’t guarantee your service will be available.  I was
> hopping to be able to do that through DS, so waiting for the DS thread
> to stop seems fine, although it would be nice to have a more formal way
> to do this, through public API.
> 
>  
> 
> In our application, we don’t expect bundles to be started and stopped
> dynamically (at least not too often), so we are really only worried
> about knowing what services there are at the initial startup.
> 
>  
> 
> I was trying to figure out a good way to safeguard against the dynamism
> of the services.  I don’t think there is an issue with the services
> which require 0..1 or 1..1 instances of another service, but I don’t
> know what to do about the services which require 0..n and 1..n because
> you don’t really know how many more services there might be without
> doing what DS seems to already do, look through the manifests and find
> the declared services.  I suppose you could also wait for the platform
> to stop starting bundles, but then DS could still be running so I’d
> still need a way to know when it was done.
> 
>  
> 
> Thanks,
> Otto
> 
>  
> 
> 
> 
> *From:* [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] *On Behalf Of *Thomas Watson
> *Sent:* Wednesday, September 03, 2008 1:30 PM
> *To:* Equinox development mailing list
> *Subject:* RE: [equinox-dev] When is DS done loading services?
> 
>  
> 
> I think part of the problem here is the term "application". In this case
> we are talking about an RCP application which is defined as an Eclipse
> extension to the org.eclipse.core.runtime.applications extension point.
> When launching Eclipse the default application is started after the
> platform has been initialized and the start-level has reached the final
> state.
> 
> RCP applications have historically depended on the platform to be "fully
> booted" and ready before their application is started. This mentality
> does not mix well with the dynamic nature of OSGi services. When DS is
> added to the mix the boot sequence become less predictable because
> services are not registered synchronously as bundles get started during
> the bootup process (incrementing the start-level). Currently the Eclipse
> application container just assumes the application is ready to launch
> after the the platform has been initialized and the final start-level
> has been reached.
> 
> To work around the issue you will need to do something like BJ says and
> make the application handle dynamic service registrations. The problem
>