Leo Simons wrote:
>
> Excellent analysis here, Berin!
> > Basically, we would have an interface for the Command object like this:
> >
> > interface Command {
> > void execute();
> > }
> >
> > We would either provide a CommandQueue, or have that command object start
> > after the Component it affects is fully set up.
>
> I'm for the latter...It makes sense to have the managing object worry about
> how to start the commands. So
>
> // ...
> myComponent.init();
> myComponent.start(); // or should this go after getCommands()?
> Iterator commands = ((Commandable)myComponent).getCommands();
> for(commands.hasNext()) {
> myThreadPool.add(new WorkerThread(commands.next()));
> }
> myComponent.run();
> myThreadPool.runAll();
> myComponent.interrupt(); // component is responsible for interrupting
> // Commands if that is neccessary
> myComponent.resume(); // component is responsible for resuming interrupted
> // commands
> myComponent.stop();
>
> // ... shutdown
> myThreadPool.stopAll(); // guaranteed before dispose()
> myThreadPool.disposeAll(); // guaranteed before dispose()
> myComponent.dispose();
> myComponent = null;
> myThreadPool = null; // last reference gone
> System.gc();
> // ...
I aggree that the commands should be executed after the Component has been
fully set up (that means after start()), and run then. I am not sure where
the myComponent.run() comes from. The start() would tell the Component to
begin (meaning background threads, etc).
> is possible. In the above (which will work with Phases in practice),
> Command would have to look like this:
>
> interface Command extends Runnable { // or we could extend Thread,
> // which means even more options
> // but also a more heavyweight
> // solution.
> void run() throws CascadingRuntimeException;
> }
I think Runnable is better. It does not force implementation issues on
the user. Thread objects are inherently run once.
> which would allow re-use of std pooling systems. It needs to be
> guaranteed that getCommands() is called after start() but before
> run(), and that the run() of the returned commands is called
> right after the run() of the component (I'm not sure this is the
> right place for those methods; important is that their point of
> execution is clearly defined).
>
> This setup has maximum flexibility while allowing complete
> manageability. I'm kinda wondering why the Command pattern was
> removed from the code...
Remember that a pattern does not mean a framework. The approach
I proposed is setting up a framework. The Timer/Scheduler Block
that was originally in Avalon was not very flexible, and the
Command object was called Alarm. When the time came for the code
to run, the Alarm object was executed. Very simple, but again,
not a framework feature.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
