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 -> [EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
