Skip to the bottom if you don't like my essay emails and just care about the questions. ;)
There are currently five states: initialized, starting, started, stopping, and stopped. These, of course, almost mimic the OSGi bundle lifecycle of installed, resolved (initialized/stopped), starting, active (started), stopping, and uninstalled. Now I prefer the OSGi lifecycle as it's a bit more explicit of a state machine, but the installed and uninstalled states only make sense in that sort of dynamic context. For a quick background on the states in OSGi, read this paragraph. Or skip it. A jar is in the installed state when you've added it to the framework. When all its dependencies are available in the framework, it is moved into the resolved state. This means it is ready to be started whenever (which is when the BundleActivator stuff gets run by the way). A bundle goes from resolved to starting, and if there are any errors starting, it goes back to resolved. Once started successfully, it goes into the active state. When a bundle is to be stopped, first it goes into stopping mode. Error or not, it transitions into the resolved state again. Finally, a bundle in the resolved state can be uninstalled which makes it unavailable from then on (it would only stick around due to memory leaks from other bundles if anything). With that in mind, I'd like to see if we can clarify on similar semantics for our LifeCycle and LifeCycle.State. 1. Should any LifeCycle object be allowed to be stopped and then started again? Or should stopping an object mean you'll have to replace it to start it again? 2. If LifeCycle objects can be restarted, what's the point in having both an initialized and a stopped state? 3. If there is an error during startup, what state should the object go into? Stopped? Initialized? Some new State like error? 4. When classes implement this, can we normally get away with using an AtomicReference<State> and the compareAndSet method instead of using synchronized or volatile booleans? I see there's a few different ways to implement life cycle state, and I think all the different ways are being used in various places. Consistency is nice. :) -- Matt Sicker <[email protected]>
