You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by RefuX Zanzeebarr <re...@hotmail.com> on 2001/08/28 22:46:27 UTC

Component Startup ordering

Ok Avalon Newbie question here :)

I have two hypothetical Components A and B.

Component A is initializable, startable, threadSafe
When start() is called, it executes a command line string.
This component also has methods to define the arguments that command line is 
called with.

Component B is Composable, threadSafe
When compose is called B gets A and defines various command line args it 
needs A to have set.



However I have situations occur when A is started before B sets the command 
line args.
Thus I have my executable running with the wrong command line args.

The ways I see to fix this are:
1. HACK: make A wait x Seconds before executing the process

2. A waits (in its own thread) until all the components are initialized (is 
there a way to determine this?),
   and then starts itself.

3. ?

I'm figuring you Avalon experts will have much better ideas that I do,
thatÂ’s why I'm asking! :)

	RefuX

p.s. Is there really much difference between a Block and a Component?
It just looks to me like the Block author has some ideas that were (for some 
reason) not rolled in to the main framework, and thus implemented as a 
different solution.



_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp


---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org


Re: Component Startup ordering

Posted by Peter Donald <do...@apache.org>.
On Wed, 29 Aug 2001 06:46, RefuX Zanzeebarr wrote:
> Ok Avalon Newbie question here :)
>
> I have two hypothetical Components A and B.
>
> Component A is initializable, startable, threadSafe
> When start() is called, it executes a command line string.
> This component also has methods to define the arguments that command line
> is called with.
>
> Component B is Composable, threadSafe
> When compose is called B gets A and defines various command line args it
> needs A to have set.
>
>
>
> However I have situations occur when A is started before B sets the command
> line args.
> Thus I have my executable running with the wrong command line args.
>
> The ways I see to fix this are:
> 1. HACK: make A wait x Seconds before executing the process
>
> 2. A waits (in its own thread) until all the components are initialized (is
> there a way to determine this?),
>    and then starts itself.
>
> 3. ?

Well in theory Component B should *never* get a reference to Component A 
before A has been fully setup (which includes calling start()). This stops B 
calling methods in A before A is ready to be accessed.

The way I would solve this would be to refactory it like so

interface CLIExecutor
{
  String ROLE = "CLIExecutor";

  void executeCLIArgs( String[] args );
}

class A implements CLIExecutor {}

That way A can be fully setup before being passed to B via ComponentManager 
and yet B can still get A to do things.

> p.s. Is there really much difference between a Block and a Component?
> It just looks to me like the Block author has some ideas that were (for
> some reason) not rolled in to the main framework, and thus implemented as a
> different solution.

Blocks are Kernel Components. It is expected they are hosted in the kernel 
and they also imply the presence of certain descriptors (ie BlockInfo/.xinfo 
descriptors etc).

Non-Block Components however don't need a kernel and don't imply presence of 
any descriptors.

-- 
Cheers,

Pete

*----------------------------------------------*
| The best defense against logic is ignorance. |
*----------------------------------------------*

---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org