You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Simons <ma...@leosimons.com> on 2001/04/23 21:42:17 UTC
more on lifecycle methods
I'm working on updating the docs (yay for me =).
Please stay away from em...
Several things popped up while updating the lifecycle
docs...
1 - Executable and Interruptable are in the proposal, but
haven't appeared in the main tree yet. Is this something
you haven't got around to yet, Pete, or is it not gonna
happen anymore?
2 - init() has not been changed to initialize() yet...will
this change?
3 - the Re<XXX> interfaces should all be updated to
extend Interruptable:
Reconfigurable extends Configurable, Interruptable
Recontextualizable extends Contextualizable, Interruptable
Recomposable extends Composable, Interruptable
4 - if we keep Parameters (and I believe no-one has a problem
with that), the next logical step would be to also define
interface Reparameterizable extends Parameterizable, Interruptable {
public void reparameterize( Parameters parameters ) throws
ParameterException;
}
5 - it is currently stated that start(), run() and stop() may be
called multiple times. I have a problem with that - some Components
may not support this behaviour (I don't think they should), while
some containers may require it. The replacement would be the use
of Commands.
A compromise might be to deprecate the repeated use of these methods
and provide commands as the alternative - gives Pete until v5 to
update to the new setup =)
6 - The proposal was to add a Commandable and a Command instead (they're
in the proposal dir), and make sure the mentioned methods are
called only once.
If we do that, I think getCommands() would go after start()/run()
and before anything else, that all returned Commands are guaranteed
to start() (as new threads) before any other method is called,
and that a Component is responsible for suspend()ing and resume()ing
Commands if that is neccessary.
Also, Command threads will run until finished, even if a Component
has already been dispose()d of. A container may choose to stop them
if they do not finish in a timely manner (the Component is once
again responsible for making sure that happens in stop() and/or
dispose()). Command threads will always be stopped and dereferenced
before a Component is dereferenced though (so finalize() on the
Component can take care of any last loose ends).
So:
...
comp.start()
comp.run()
cmds = comp.getCommands()
runAll(cmds)
comp.suspend()
comp.resume()
comp.suspend()
comp.resume()
cmds.stop()
cmds.dispose()
...
while(! exit ) {
stopAll(cmds)
cmds = null;
comp = null;
System.gc(); // finalize() called on comp
}
can I have votes/comments on 1-6 where neccessary?
regards,
LSD
PS: what I'm doing with the docs? Two things. The first
one is changing all the language and some of the
organisation so things are easier to follow (you guys
have a 'nack for using complicated terms =), the second
is updating the docs to reflect recent changes.
<java:sig>
About LSD = new PersonalInfo();
LSD.name("Leo Simons");
LSD.email("mail@leosimons.com");
LSD.URL( [
http://www.leosimons.com, // personal website
http://www.atfantasy.com, // fantasy RPG portal
http://www.the-sign.nl // web-design company
] );
LSD.quote("Buh!");
email.setSig((String)LSD);
</java:sig>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: more on lifecycle methods
Posted by Peter Donald <do...@apache.org>.
At 04:21 23/4/01 -0400, Berin Loritsch wrote:
>Leo Simons wrote:
>>
>> I'm working on updating the docs (yay for me =).
>> Please stay away from em...
>>
>> Several things popped up while updating the lifecycle
>> docs...
>>
>> 1 - Executable and Interruptable are in the proposal, but
>> haven't appeared in the main tree yet. Is this something
>> you haven't got around to yet, Pete, or is it not gonna
>> happen anymore?
>
>I think it's something that we just haven't gotten around to
>yet. I also think Peter is wanting to keep the Startable/Stopable
>interfaces to avoid alot of rework in some of his already
>written code.
I can always rework it though it would be a pain ;) However at the moment I
am more concerned about naming.
>Also, I believe that the Runnable interface usually tied to Executable
>should be handled by the Component, not necessarily the framework. It
>is assumed that between start() and stop(), we are executing the code
>for run().
I am removed Runnable stage a while back due to just this reason and
because it had lots of undefined behaviour. I pinged the list a few times
but no one had any issues so ... ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: more on lifecycle methods
Posted by Berin Loritsch <bl...@apache.org>.
Leo Simons wrote:
>
> I'm working on updating the docs (yay for me =).
> Please stay away from em...
>
> Several things popped up while updating the lifecycle
> docs...
>
> 1 - Executable and Interruptable are in the proposal, but
> haven't appeared in the main tree yet. Is this something
> you haven't got around to yet, Pete, or is it not gonna
> happen anymore?
I think it's something that we just haven't gotten around to
yet. I also think Peter is wanting to keep the Startable/Stopable
interfaces to avoid alot of rework in some of his already
written code.
> 2 - init() has not been changed to initialize() yet...will
> this change?
If you want to commit the change, go ahead. I think we all
+1ed on this one.
> 3 - the Re<XXX> interfaces should all be updated to
> extend Interruptable:
>
> Reconfigurable extends Configurable, Interruptable
> Recontextualizable extends Contextualizable, Interruptable
> Recomposable extends Composable, Interruptable
I see what you are saying, however, the mechanism that developers
use may not necessarily be the Interruptable interface. The
contract simply says that the component must remain in a consistent
state during reconfiguration. This could simply be done with a
Lock object that is released when reconfiguration is finished.
I think in this respect we should not tie the implementation of
the Interruptable interface to the Re*able interfaces. Especially
since they can be passive objects (not Executable or Interruptable).
> 4 - if we keep Parameters (and I believe no-one has a problem
> with that), the next logical step would be to also define
>
> interface Reparameterizable extends Parameterizable, Interruptable {
>
> public void reparameterize( Parameters parameters ) throws
> ParameterException;
>
> }
Agreed, with the exception of the Interruptable interface (see above).
> 5 - it is currently stated that start(), run() and stop() may be
> called multiple times. I have a problem with that - some Components
> may not support this behaviour (I don't think they should), while
> some containers may require it. The replacement would be the use
> of Commands.
> A compromise might be to deprecate the repeated use of these methods
> and provide commands as the alternative - gives Pete until v5 to
> update to the new setup =)
Think of a J2EE server. It should be possible for the administrator
to stop and restart the Servlet Container as many times as they need.
The important contracts to maintain are that start() cannot be called
before initialize(), and stop() cannot be called after dispose(), and
that Interruptable methods cannot be called when the component is
stopped.
> 6 - The proposal was to add a Commandable and a Command instead (they're
> in the proposal dir), and make sure the mentioned methods are
> called only once.
> If we do that, I think getCommands() would go after start()/run()
> and before anything else, that all returned Commands are guaranteed
> to start() (as new threads) before any other method is called,
> and that a Component is responsible for suspend()ing and resume()ing
> Commands if that is neccessary.
> Also, Command threads will run until finished, even if a Component
> has already been dispose()d of. A container may choose to stop them
> if they do not finish in a timely manner (the Component is once
> again responsible for making sure that happens in stop() and/or
> dispose()). Command threads will always be stopped and dereferenced
> before a Component is dereferenced though (so finalize() on the
> Component can take care of any last loose ends).
> So:
>
> ...
> comp.start()
> comp.run()
> cmds = comp.getCommands()
> runAll(cmds)
> comp.suspend()
> comp.resume()
> comp.suspend()
> comp.resume()
> cmds.stop()
> cmds.dispose()
> ...
>
> while(! exit ) {
> stopAll(cmds)
> cmds = null;
> comp = null;
> System.gc(); // finalize() called on comp
> }
>
> can I have votes/comments on 1-6 where neccessary?
Personally, I think that the Command infrastructure should be considered
as a mutually exclusive relationship to Executable/Interruptable.
However, since this is nearly impossible to enforce, I will agree to
your lifecycle proposal for their placement.
Also, I believe that the Runnable interface usually tied to Executable
should be handled by the Component, not necessarily the framework. It
is assumed that between start() and stop(), we are executing the code
for run().
>
> regards,
>
> LSD
>
> PS: what I'm doing with the docs? Two things. The first
> one is changing all the language and some of the
> organisation so things are easier to follow (you guys
> have a 'nack for using complicated terms =), the second
> is updating the docs to reflect recent changes.
:)
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: more on lifecycle methods
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
>
> At 11:25 24/4/01 +0200, Leo Simons wrote:
> >In response to Peter:
> >> no idea - I would -1 the Executable name in favour of something else
> >> (Animatable or Active???). Still can't think of a good name for
> >> Interruptable thou ;)
> >
> >Component == Passive entity
> >Composer/Composable == Active entity
> >
> >So that's not a real option.
>
> Do you like Animated then ?
Animated (to me) connotates the whole kit and kaboodle of something that
is fully state managed by the kernel. That means start, stop, pause,
resume, or any other state.
> >Why was it again that Interruptable was a bad name? Perhaps...
> >...scratches head...can't think of anything else either ;/
>
> Interruptable implies either of the following
>
> interface Interruptable {} //ie maarker interface
> interface Interruptable
> {
> void interrupt();
> }
>
> because that is a fairly established pattern. Don't know of anything better
> though .... may scrounge through saw thesaurus/dictionary.
That's a tough one.
> >> -1 on adding commands at this stage
> >
> >I agree. Untested code should not go in a beta. But do we move there in
> >the future or not?
>
> yep - but I am not sure the proposed design was something desirable yet.
> What you called Commands are traditionally called Task/Jobs. Before we
> adopt anything we should check out existing research (and there is a lot
> about it) aswell as prototype it a bit ;)
Agreed.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: more on lifecycle methods
Posted by Leo Simons <ma...@leosimons.com>.
> >> no idea - I would -1 the Executable name in favour of something else
> >> (Animatable or Active???). Still can't think of a good name for
> >> Interruptable thou ;)
> >
> >Component == Passive entity
> >Composer/Composable == Active entity
> >
> >So that's not a real option.
>
> Do you like Animated then ?
Not really...but I dunno a better one...so here's a +0
> >> -1 on adding commands at this stage
> >
> >I agree. Untested code should not go in a beta. But do we move there in
> >the future or not?
>
> yep - but I am not sure the proposed design was something desirable yet.
> What you called Commands are traditionally called Task/Jobs. Before we
> adopt anything we should check out existing research (and there is a lot
> about it) aswell as prototype it a bit ;)
mine is similar to code found in a WikiWikiWeb somewhere,
as well as what Bruce Eckel proposes in his preliminary
"Thinking in patterns with Java".
I've seen queues, proxies, and more. This is probably the
simplest one.
...
I also saw a great Task library for C++ recently...now where
do I have that...
gotta go!
LSD
<java:sig>
About LSD = new PersonalInfo();
LSD.name("Leo Simons");
LSD.email("mail@leosimons.com");
LSD.URL( [
http://www.leosimons.com, // personal website
http://www.atfantasy.com, // fantasy RPG portal
http://www.the-sign.nl // web-design company
] );
LSD.quote("Buh!");
email.setSig((String)LSD);
</java:sig>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: more on lifecycle methods
Posted by Peter Donald <do...@apache.org>.
At 11:25 24/4/01 +0200, Leo Simons wrote:
>In response to Peter:
>> no idea - I would -1 the Executable name in favour of something else
>> (Animatable or Active???). Still can't think of a good name for
>> Interruptable thou ;)
>
>Component == Passive entity
>Composer/Composable == Active entity
>
>So that's not a real option.
Do you like Animated then ?
>Why was it again that Interruptable was a bad name? Perhaps...
>...scratches head...can't think of anything else either ;/
Interruptable implies either of the following
interface Interruptable {} //ie maarker interface
interface Interruptable
{
void interrupt();
}
because that is a fairly established pattern. Don't know of anything better
though .... may scrounge through saw thesaurus/dictionary.
>> -1 on adding commands at this stage
>
>I agree. Untested code should not go in a beta. But do we move there in
>the future or not?
yep - but I am not sure the proposed design was something desirable yet.
What you called Commands are traditionally called Task/Jobs. Before we
adopt anything we should check out existing research (and there is a lot
about it) aswell as prototype it a bit ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: more on lifecycle methods
Posted by Charles Benett <ch...@benett1.demon.co.uk>.
Peter Donald wrote:
>
> At 09:42 23/4/01 +0200, Leo Simons wrote:
> >I'm working on updating the docs (yay for me =).
> >Please stay away from em...
> >2 - init() has not been changed to initialize() yet...will
> >this change?
>
> Charles vetoed it and I have got around to challengine it yet - until that
> happens we can't change it ;)
I'll change my -1 to a -0. I still prefer init() because it is short and
perfectly satisfactory.
Charles
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: more on lifecycle methods
Posted by Berin Loritsch <bl...@apache.org>.
Leo Simons wrote:
>
> > > 5 - it is currently stated that start(), run() and stop() may be
> > > called multiple times. I have a problem with that - some Components
> > > may not support this behaviour (I don't think they should), while
> > > some containers may require it. The replacement would be the use
> > > of Commands.
> >
> > Think of a J2EE server. It should be possible for the administrator
> > to stop and restart the Servlet Container as many times as they need.
> > The important contracts to maintain are that start() cannot be called
> > before initialize(), and stop() cannot be called after dispose(), and
> > that Interruptable methods cannot be called when the component is
> > stopped.
>
> Yep. But a Container now needs to distinguish between a Component that
> only allows start() and stop() to be run once (which imo should be
> possible),
> and a Component that allows it to happen multiple times.
> How do we do that?
I different contract warrants a different interface. Perhaps an interface
that inherits from Executable called Unrestartable? Something along those
lines anyway. The interface could also merely be a merker interface called
RunOnce or something more snazzy.
You get the idea.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: more on lifecycle methods
Posted by Leo Simons <ma...@leosimons.com>.
In response to Peter:
> no idea - I would -1 the Executable name in favour of something else
> (Animatable or Active???). Still can't think of a good name for
> Interruptable thou ;)
Component == Passive entity
Composer/Composable == Active entity
So that's not a real option.
Processable?
Process?
Threadable?
Program?
Why was it again that Interruptable was a bad name? Perhaps...
...scratches head...can't think of anything else either ;/
> -1 on adding commands at this stage
I agree. Untested code should not go in a beta. But do we move there in
the future or not?
In response to Berin:
> I see what you are saying, however, the mechanism that developers
> use may not necessarily be the Interruptable interface. The
> contract simply says that the component must remain in a consistent
> state during reconfiguration. This could simply be done with a
> Lock object that is released when reconfiguration is finished.
> I think in this respect we should not tie the implementation of
> the Interruptable interface to the Re*able interfaces. Especially
> since they can be passive objects (not Executable or Interruptable).
Oh. Uhm. Yes. Totally correct =)
> > 5 - it is currently stated that start(), run() and stop() may be
> > called multiple times. I have a problem with that - some Components
> > may not support this behaviour (I don't think they should), while
> > some containers may require it. The replacement would be the use
> > of Commands.
>
> Think of a J2EE server. It should be possible for the administrator
> to stop and restart the Servlet Container as many times as they need.
> The important contracts to maintain are that start() cannot be called
> before initialize(), and stop() cannot be called after dispose(), and
> that Interruptable methods cannot be called when the component is
> stopped.
Yep. But a Container now needs to distinguish between a Component that
only allows start() and stop() to be run once (which imo should be
possible),
and a Component that allows it to happen multiple times.
How do we do that?
> Personally, I think that the Command infrastructure should be considered
> as a mutually exclusive relationship to Executable/Interruptable.
Me too, however...
> However, since this is nearly impossible to enforce, I will agree to
> your lifecycle proposal for their placement.
cool beans.
> Also, I believe that the Runnable interface usually tied to Executable
> should be handled by the Component, not necessarily the framework. It
> is assumed that between start() and stop(), we are executing the code
> for run().
Also agree on that one; it is unclear to me how far we are in
changing this (checking)...almost done. I'll update the lifecycle
doc =)
...
I think Commands should be used as untested code currently in
excalibur.command, that may move to a more prominent place if
it is used.
cheers!
LSD
<java:sig>
About LSD = new PersonalInfo();
LSD.name("Leo Simons");
LSD.email("mail@leosimons.com");
LSD.URL( [
http://www.leosimons.com, // personal website
http://www.atfantasy.com, // fantasy RPG portal
http://www.the-sign.nl // web-design company
] );
LSD.quote("Buh!");
email.setSig((String)LSD);
</java:sig>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: more on lifecycle methods
Posted by Peter Donald <do...@apache.org>.
At 09:42 23/4/01 +0200, Leo Simons wrote:
>I'm working on updating the docs (yay for me =).
>Please stay away from em...
>
>Several things popped up while updating the lifecycle
>docs...
>
>1 - Executable and Interruptable are in the proposal, but
>haven't appeared in the main tree yet. Is this something
>you haven't got around to yet, Pete, or is it not gonna
>happen anymore?
no idea - I would -1 the Executable name in favour of something else
(Animatable or Active???). Still can't think of a good name for
Interruptable thou ;)
>2 - init() has not been changed to initialize() yet...will
>this change?
Charles vetoed it and I have got around to challengine it yet - until that
happens we can't change it ;)
>3 - the Re<XXX> interfaces should all be updated to
>extend Interruptable:
>
>Reconfigurable extends Configurable, Interruptable
>Recontextualizable extends Contextualizable, Interruptable
>Recomposable extends Composable, Interruptable
I need to think about that and look how I use Re* in my code.
>4 - if we keep Parameters (and I believe no-one has a problem
>with that), the next logical step would be to also define
>
>interface Reparameterizable extends Parameterizable, Interruptable {
>
> public void reparameterize( Parameters parameters ) throws
>ParameterException;
>
>}
Possibly - though not sure it is needed - I guess thats a lets talk about
it point ;)
>5 - it is currently stated that start(), run() and stop() may be
>called multiple times. I have a problem with that - some Components
>may not support this behaviour (I don't think they should), while
>some containers may require it. The replacement would be the use
>of Commands.
>A compromise might be to deprecate the repeated use of these methods
>and provide commands as the alternative - gives Pete until v5 to
>update to the new setup =)
-1 on adding commands at this stage
+1 at fixing docs
Need more thought about start/stop only callable once - I wouldn't have
problem with changing to this behaviour I don't think.
>6 - The proposal was to add a Commandable and a Command instead (they're
>in the proposal dir), and make sure the mentioned methods are
>called only once.
>If we do that, I think getCommands() would go after start()/run()
>and before anything else, that all returned Commands are guaranteed
>to start() (as new threads) before any other method is called,
>and that a Component is responsible for suspend()ing and resume()ing
>Commands if that is neccessary.
>Also, Command threads will run until finished, even if a Component
>has already been dispose()d of. A container may choose to stop them
>if they do not finish in a timely manner (the Component is once
>again responsible for making sure that happens in stop() and/or
>dispose()). Command threads will always be stopped and dereferenced
>before a Component is dereferenced though (so finalize() on the
>Component can take care of any last loose ends).
>So:
>
>...
>comp.start()
>comp.run()
>cmds = comp.getCommands()
>runAll(cmds)
>comp.suspend()
>comp.resume()
>comp.suspend()
>comp.resume()
>cmds.stop()
>cmds.dispose()
>...
>
>while(! exit ) {
> stopAll(cmds)
> cmds = null;
> comp = null;
> System.gc(); // finalize() called on comp
>}
>
>can I have votes/comments on 1-6 where neccessary?
-1 because untested and late. It is similar to a lot of task based systems
that written or are involved in (Ant - yaya!) or are in frameworks (such as
ACE or concurrent from that smart guy). However we need testing.
>PS: what I'm doing with the docs? Two things. The first
>one is changing all the language and some of the
>organisation so things are easier to follow (you guys
>have a 'nack for using complicated terms =), the second
>is updating the docs to reflect recent changes.
kewl. Most likely all the inverted sentances were mine - I was a
philosophy/logic student for waaaay too long ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org