Mailing-List: contact log4j-dev-help@logging.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Log4J Developers List" <log4j-dev@logging.apache.org>
Received-SPF: pass (nike.apache.org: domain of boards@gmail.com designates
 209.85.219.47 as permitted sender)
MIME-Version: 1.0
Date: Sat, 13 Sep 2014 15:45:53 -0500
Message-ID: 
 <CACmp6kp1XTQ9Bq=zPcpbf1OeVV6bwuD+xogieJYYeX0xxE5jOA@mail.gmail.com>
Subject: Would anyone be against simply copying the lifecycle standards from
 OSGi?
From: Matt Sicker <boards@gmail.com>
To: Log4J Developers List <log4j-dev@logging.apache.org>
Content-Type: multipart/alternative; boundary=001a113ce460d6601e0502f87c8b

--001a113ce460d6601e0502f87c8b
Content-Type: text/plain; charset=UTF-8

They're the most flexible. Quick overview of the life cycle in OSGi:

installed -> resolved -> (starting) -> active -> (stopping) resolved ->
uninstalled

Installed is the initial state. Resolved is when all its dependencies have
been fulfilled. During the starting state, if there is an error, then it
goes back to resolved. Active for while it's, well, active. Stopping puts
the thing back into resolved. Then, if you go from resolved to uninstalled,
this means that it's no longer available for use (and the only reason you'd
find something in this state for very long is due to a memory leak).

Any objections? This would make our LifeCycle interface more compatible
with OSGi while providing a well-understood standard for the life cycle of
plugin-type objects.

-- 
Matt Sicker <boards@gmail.com>

--001a113ce460d6601e0502f87c8b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>They&#39;re the most flexible. Quick overview of=
 the life cycle in OSGi:<br><br></div>installed -&gt; resolved -&gt; (start=
ing) -&gt; active -&gt; (stopping) resolved -&gt; uninstalled<br><br>Instal=
led is the initial state. Resolved is when all its dependencies have been f=
ulfilled. During the starting state, if there is an error, then it goes bac=
k to resolved. Active for while it&#39;s, well, active. Stopping puts the t=
hing back into resolved. Then, if you go from resolved to uninstalled, this=
 means that it&#39;s no longer available for use (and the only reason you&#=
39;d find something in this state for very long is due to a memory leak).<b=
r><br></div>Any objections? This would make our LifeCycle interface more co=
mpatible with OSGi while providing a well-understood standard for the life =
cycle of plugin-type objects.<br clear=3D"all"><div><div><div><br>-- <br>Ma=
tt Sicker &lt;<a href=3D"mailto:boards@gmail.com" target=3D"_blank">boards@=
gmail.com</a>&gt;
</div></div></div></div>

--001a113ce460d6601e0502f87c8b--