avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@apache.org>
Subject Re: thinking Merlin/Pheoix stuff ...
Date Wed, 05 Jun 2002 07:58:27 GMT
On Wed, 5 Jun 2002 16:21, Stephen McConnell wrote:
> >It must be possible for those constriants to be declared by component who
> >needs them and then if the container understands constriant it must be
> > able to validate this somehow.
> Specifically - (a) composer aggregates constraints from possibly
> multiple component meta declarations, (b) composer creates dependent
> component/s and supplied constraint/s as part of lifecycle/lifestyle
> processing, (c) container handles constraint validation (d) composer
> supplies assembled container to the target component.
> Where composer == Merline/Phoenix/...
> Container ==  any composite component (e.g. an ORB)
> Component == the thing declaring the dependecy constraints

Thats diferent from what I am thinking atm. Using my own terminology cause 
yours sucks ;)

Component A = thing declaring dependencies
Component B = a composite component that A depends upon
Constraint x, y, z = Constraints that A requires from B
Kernel = Merlin/Phoenix

The process would be;

* Kernel creates B and does its lifecycle stuff
* Kernel creates A
* Kernel checks to see if B satisfies constraints x, y and z
* Kernel sets up A using service B

Note that at no point was B informed that it had to satisfy constraints x, y, 
z - that is part of assemblers job to get right, not developers job IMHO.

Thus it becomes up to container to interpret/validate constraints and up to 
assembler to assemble an application correctly. Basically comes back to my 
dislike of putting assembly information in the BlockInfo files.


Peter Donald
"An intellectual is someone who has been educated 
beyond their intelligence."

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

View raw message