I still need to think about this. I'll have time tomorrow... Gary
On Fri, Aug 8, 2014 at 10:05 PM, Matt Sicker <[email protected]> wrote: > 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]> > -- E-Mail: [email protected] | [email protected] Java Persistence with Hibernate, Second Edition <http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
