Re: [equinox-dev] Starting equinox framework in program
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 equinox-dev@eclipse.org | --| | | 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 inline: graycol.gifinline: ecblank.gif___ 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] When is DS done loading services?
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?
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?
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 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,
Re: [equinox-dev] When is DS done loading services?
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 when
Re: [equinox-dev] When is DS done loading services?
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_ http://www.osgi.org/_ [EMAIL PROTECTED] mailto:[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 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 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 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?
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 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 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_ http://www.osgi.org/_ [EMAIL PROTECTED] mailto:[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?
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
[equinox-dev] Project meta data is out of date for rt.equinox
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 project 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
