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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
