Now that LifeCycle classes are Serializable as well, it might be a good idea to revisit this idea. Upon serializing and then deserializing, should we go back into the INITIALIZED state or what?
On 10 August 2014 11:14, Gary Gregory <[email protected]> wrote: > 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 > -- Matt Sicker <[email protected]>
