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 Thu, 06 Jun 2002 00:52:51 GMT
Thats kinda kool. Need time to digest it though. One thing I would prefer 
is to not have component participate in constraint validation.

At 10:20 AM 6/5/2002 -0400, you wrote:
>On Tuesday 04 June 2002 07:20 pm, Peter Donald wrote:
> > 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.
>
>Here's something weird and off-the-wall.
>
>Ideally, we would want container-agnostic constraints, correct?
>
>And in most (all?) cases there is a container-containee heirarchy with a root
>container at the top, ala (sorry my ascii art skills are sub-par)
>
>                     +----------------+
>                     | Root Container |
>                     +--+-------------+
>                        |
>     +-----------+------+-----+
>  +-------+  +-------+     +--------+
>  | Comp1 |  | Comp2 |     | Comp3  |
>  +-------+  +---+---+     +--------+
>                 |
>           +-----+----+
>    +---------+     +---------+
>    | SubComp1|     | SubComp2|
>    +---------+     +---------+
>
>
>How about using XPath expression?
>
>Peter's examples above could be written as:
>
><constraint value="o.c.TimeServer/@initialized"/>
><constraint value="o.c.BlahServer/@initialized"/>
>
>various lifecycle stages could be represented as "attributes" upon roles,
>"elements". The container is responsible for the mapping. My inspiration for
>this is from Jaxen (http://jaxen.org) which lets you execute XPath
>expressions against arbitrary object models (or anything you can represent as
>an element-attribute heirarchy) by subclassing their
>org.jaxen.DefaultNavigator class. Different containers could have their own
>implementations to perform the mapping as needed for their internals.
>
>Or for something more complex, say Comp1 needed a SocketServer with SSL
>sockets, we could do
>
><constraint
>value="component-exists(o.a.a.cornerstone.service.sockets.SocketManager/ssl)">
>
>But then how does the container know to determine if the SocketManager has a
>specified socket type? It doesn't. It just knows how to pass the constraint
>resolution onto the SocketManager. SocketManager could implement an interface
>such as ConstraintResolveable that would indicate to a container that it
>knows how to resolve contraints that delve into its internal component
>structure that the container may be unaware of.
>
>Sometimes expressing everything as XML can become unweildy. (i have a
>hammer.. etc etc).
>
>But just some seriously random thoughts. Fire away and ask questions.
>-pete
>
>--
>peter royal -> proyal@apache.org
>
>--
>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>



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