I do not think we should bother with that for now. The initial goes should be to get the Log4j objects to Serialize for people who do not or cannot declare Loggers (for example) as volatile.
Gary On Tue, Aug 26, 2014 at 12:07 AM, Matt Sicker <[email protected]> wrote: > 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]> > -- 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
