----- Original Message ----- Ok, thanks. One further question. Let's say my service performs some async action in start() and when that action is finished I'm not really interested in the service any more. Should I remove it somehow from the system then? Additionally, let's say I have a service that can run more than once, should I give it a different name every time? Cheers, David

On 06/01/2011 03:08 PM, David Bosschaert wrote: In other words, a one-time task which is triggered when all its dependencies start? We don't have a generalized API for this. There are subtle conceptual issues. First, using a service will cause its dependencies to automatically start if they are, say, ON_DEMAND. However if your service then immediately stops or is removed, the dependency services will stop again, which is not a useful semantic. You can use listeners instead, however a listener can only presently be added to an installed service (i.e. you can't install a listener on a name in anticipation of a future service). So the real question is, what problem are you trying to solve here? Services can be stopped and started repeatedly, and in fact it is part of the contract of a service that it must be able to do so. -- - DML

On 06/01/2011 04:05 PM, David Bosschaert wrote: It depends on the required semantics. If all bundles in the entire system have to be installed first and then started, then you should have a "barrier" service which depends on the install phase service for all bundles system-wide, and upon which the start phase service for all bundles depends. When new bundles are added you'd then have to remove and replace this barrier service, causing all bundles to be stopped and re-started again. This is obviously a pretty clunky solution. Another solution is to simply directly control the service via a mode setting. This is also clunky, but in a different way - a user messing with service modes via a console for example can screw up the installation process of OSGi bundles (contrast with other deployment types which can use dependencies for everything). Ideally there'd be a way to frame this lock-step semantic in terms of a fixed dependency specification. In other words, don't think in terms of what is required for a bundle to be started (as a transitional action), but rather what is required for a bundle to be in the "started" state. In other, other words, think about the criteria which must be true in order for a bundle to not stop automatically. This will cause a problem if the service is re-started for some reason (i.e. a [possibly distantly transitive] dependency is removed causing all dependents to stop and then the problem is resolved causing dependents to re-start). -- - DML