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 05:08:04 GMT
On Wed, 5 Jun 2002 13:44, Stephen McConnell wrote:
> Peter Donald wrote:
> >On Wed, 5 Jun 2002 05:34, Stephen McConnell wrote:
> >>  <dependencies>
> >>     <dependency>
> >>
> >>         <!-- declaration of a classic dependency -->
> >>
> >>         <role>orb</role>
> >>         <service name="org.apache.orb.ORB" version="2.4">
> >
> >I have been experimenting with something like
> >
> ><constraint type="initializer" value="o.c.TimeServer"/>
> ><constraint type="initializer" value="o.c.BlahServer"/>
> >
> >The constraints will be container specific but can do most of what I
> > wanted but so far the experients been less than successful.
>
> Two questions:
> 1. What's the specific objective of the experiments?

To see if it is possible to do one/any of the following
* declare constraints in some generic fashion. Generic enough that it can do 
the following;
  - declare an ORB must contain components at end of startup
  - declare that a component must be scoped/nestable (constraint from myrmidon 
dev for scopes such as workspace, project, target, task etc). Basically means 
that the component must implement another "lifestyle" interface with a single 
method.
  - declare that component must be safely accessible from multiple threads 
(bit of cocoon action). ie Component must belong to a certain lifestyle 
(independt of above).
 - a few othres which are written on pad next to computer in office which I 
can't remember ;)

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.

> 2. What approach are you using for supply constraints to the service
> your creating?

Component A declares it needs a Component of type P with constrains x, y, z. 
The container validates constraints in a container specific manner. Most 
should be able to be done at assembly time (like lifestyle, or if it 
implements other attributes like "MT" etc). Some may have to be delayed to 
post initialization time (eww).

Currently I am just doing lots of little ugly hacks ontop of phoenix so that 
blockinfo can look like

<dependency>
  <service .../>
  <constraint type="lifestyle" value="multithreaded"/>

  <constraint type="contains">
    <component name="XImpl" type="o.a.a.X"/>
    <component name="YImpl" type="o.a.a.Y"/>
  </constraint>

</dependency>

Playing with format of constrains from opaque strings to nested configuration 
trees or parameters lists etc.

-- 
Cheers,

Peter Donald
------------------------------------------------------
 Mark Twain: "In the real world, the right thing never
happens in the right place at the right time. It is 
the task of journalists and historians to rectify 
this error."
------------------------------------------------------ 


--
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>


Mime
View raw message