logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sicker <boa...@gmail.com>
Subject Question regarding semantics of LifeCycle.
Date Sat, 09 Aug 2014 02:05:44 GMT
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

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 <boards@gmail.com>

View raw message