Hi Regarding subsystem.start() and subsystem.stop(), here is my understanding:
start(): Upon entering the method, we change the subsystem state to STARTING. Then we start composite bundle and all its constituents according to their start level. If any of the constituent's start policy is lazy, the bundle is going to be in state STARTING. Whenever this method finishes without any exception, we change the subsystem state to ACTIVE. If there is exception arisen, we change the subsystem state to ??? state. stop(): Upon entering the method, we change the subsystem state to STOPPING. Then we stop all its constituents and the composite bundle. Whenever this method finishes without any exception, we change the subsystem state to RESOLVED. If there is exception arisen, we change the subsystem state to ??? state. For ??? state, we are not sure what state it is now, as it can be some bundles still active, some bundles stopped. Maybe we should add a new state called UNKNOWN and set the state to UNKNOWN. Thanks Lin On Sat, Apr 3, 2010 at 2:11 AM, Guillaume Nodet <[email protected]> wrote: >> I do not see how it can represent the aggregate state. If we have 10 >> bundles in a subsystem where >> half are started and half stopped what would the aggregate state be? >> In fact is this even a problem? Perhaps >> this is the normal state. I think that the first thing to decide is >> what does it mean to start and stop a subsystem. >> Once we know what that means we can decide if a relationship with the >> bundles in a subsystem makes sense. >> >> Well, imho, we already have the low level life cycle from the composites. > If we could go higher in the abstraction that would be nice. > So I would assume bundles from inside the subsystem could be marked somehow > has being started or not (I would also assume a default value of started). > When the subsystem is installed, those bundles would be started (well, not > really > started because the composite itself is not, but at least they would be > marked as > persistently started). Starting the subsystem would start the composite > which in turns > would start the inner bundles. (we could also maybe handle start levels for > each bundle). > Now, I don't think having the bundles ACTIVE is sufficient to describe the > good health > of the subsystem. But I also agree it might be difficult to understand that > the user mean > by started without custom code to check the health of individual bundles.
