You are viewing a plain text version of this content. The canonical link for it is here.
Posted to phoenix-dev@avalon.apache.org by Peter Donald <pe...@apache.org> on 2002/06/01 09:04:15 UTC
Re: thinking Merlin/Pheoix stuff ...
On Fri, 31 May 2002 17:59, Stephen McConnell wrote:
> Looking at a real example - the assembly of an ORB - the information
> supplied to an ORB to assemble itself is specific to an ORB component.
> As shown in the above example, its a bunch of interceptor declarations.
The problem is that there is no way that I can think of of passing in
configuration without restricting yourself to a particular implementation.
For instance most roles/interfaces can have multiple implementations.
One implementation may require configuration, one may not require
configuration (it may be fixed at compile time), one configuration schema may
be different from another. One implementation may have similar contained
components but represented completely and utterly differently or whatever. ie
Are interceptors specific to OpenORB implementation? or are they generic
across all Corba ORBs?
We came across similar problems with hierarchial configuration. ie Where
configuration for component A is inside component B's configuration. We can't
really determine that component B even has a sub-component A unless we
instantiate B and let B interpret its own configuration. (Or unless we
standardize the format of all configuration schemas which does not seem
feasible).
Our conclusion wrt to Configuration was that we should not have hierarchial
configuration at all or that we should validate it at runtime (effectively
each container component validates all the childrens schemas).
It may be possible to do similar validation of a "Container" component at
runtime. ie Every Container object implements a particular interface that
either
* exposes metadata about contained components (preferrable)
* exposes the contained objects directly (icky)
HOwever until we get common metainfo representaiton across all avalon I am not
sure the first is an option.
Hmmm not sure.
--
Cheers,
Peter Donald
*------------------------------------------------------*
| "Common sense is the collection of prejudices |
| acquired by age 18. " -Albert Einstein |
*------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: thinking Merlin/Pheoix stuff ...
Posted by Peter Royal <pr...@apache.org>.
On Wednesday 05 June 2002 08:52 pm, Peter Donald wrote:
> Thats kinda kool. Need time to digest it though. One thing I would prefer
> is to not have component participate in constraint validation.
Understandable.
There needs to be a generic way for a child container to report information
about its components to its parent container for constraint resolution.
Perhaps your newly-created MetaInfo object will work, a component can
optionally offer metainfo on its child components.
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: thinking Merlin/Pheoix stuff ...
Posted by Peter Donald <pe...@apache.org>.
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: <ma...@jakarta.apache.org>
>For additional commands, e-mail:
><ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: thinking Merlin/Pheoix stuff ...
Posted by Peter Royal <pr...@apache.org>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: thinking Merlin/Pheoix stuff ...
Posted by Peter Donald <pe...@apache.org>.
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.
--
Cheers,
Peter Donald
--------------------------------------------------
"An intellectual is someone who has been educated
beyond their intelligence."
--------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: thinking Merlin/Pheoix stuff ...
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Peter Royal [mailto:proyal@apache.org]
>
> On Wednesday 05 June 2002 04:10 am, Peter Donald wrote:
> > If you register a type at workspace level then it will be visible to
all
> > tasks in all projects. If you register type in one project (say via
a
> > taskdef) then it will only be accessible by that project and not any
other
> > projects in workspace.
> ...
> > Anyways - what about mounted Cocoon sitemaps - are they similar?
>
> Yes. A sitemap can contain sub-sitemaps. Components declared in a
sitemap are
> visible in that sitemap and all of its sub-sitemaps. If you have
something
> like
>
> A
> / \
> / \
> B C
>
> Where A is a sitemap and B and C are sub-sitemaps, if a component is
declared
> in B it is not visible to C ( and could be re-declared in C, which is
a
> potential point of problems for naive users, especially if the
component is
> pooled and you now have two pools of the same component. eek!)
But they could have different configuration! Say, connected to different
servers...
Vadim
> -pete
>
> --
> peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: thinking Merlin/Pheoix stuff ...
Posted by Peter Royal <pr...@apache.org>.
On Wednesday 05 June 2002 04:10 am, Peter Donald wrote:
> If you register a type at workspace level then it will be visible to all
> tasks in all projects. If you register type in one project (say via a
> taskdef) then it will only be accessible by that project and not any other
> projects in workspace.
...
> Anyways - what about mounted Cocoon sitemaps - are they similar?
Yes. A sitemap can contain sub-sitemaps. Components declared in a sitemap are
visible in that sitemap and all of its sub-sitemaps. If you have something
like
A
/ \
/ \
B C
Where A is a sitemap and B and C are sub-sitemaps, if a component is declared
in B it is not visible to C ( and could be re-declared in C, which is a
potential point of problems for naive users, especially if the component is
pooled and you now have two pools of the same component. eek!)
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: thinking Merlin/Pheoix stuff ...
Posted by Peter Donald <pe...@apache.org>.
Hi,
Cross-posting to avalon-dev as I believe that the Cocooners have notion of
scope as they can have sitemaps "mounted" in other sitemaps which is similar.
Thus they probably be able to explain their implementation.
On Wed, 5 Jun 2002 16:21, Stephen McConnell wrote:
> Peter Donald wrote:
> >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.
>
> Can you provide some relevant links (i.e. more relevant then the root
> myrmidon) so I can get a better feel for the implication of scopes?
Unfortunately most of the information is located in Adams head (another active
developer on myrmidon) so I am not sure I could explain it fully ;)
However the basic idea is as follows;
Each component lives in a "scope" or environment. For instance myrmidon has
components such as
* ConverterManager
* TypeManager
* Configurator
* Executor
Now for some of these components (TypeManager for instance) you can create
Child objects. The TypeManager child allows you to register extra types.
These types are visible to current TypeManager and all child TypeManagers
(unless they get overidden).
So lets say we have scopes;
* workspace
* project
* target
* task
* sub-tasks
If you register a type at workspace level then it will be visible to all tasks
in all projects. If you register type in one project (say via a taskdef) then
it will only be accessible by that project and not any other projects in
workspace.
This phenomenon can be nested as far as you want to go (ie tasks can create
their own scopes and execute child tasks inside them).
A naive implementation would have each service implement a createChildX method
if needed. However what happens when the Configurator depends on TypeManager
and a child TypeManager is created. This means a child Configurator has to be
created or an exception has to be thrown (or warning issued or whatever).
Anyways - what about mounted Cocoon sitemaps - are they similar?
--
Cheers,
Peter Donald
---------------------------------------------------
"Wise men don't need advice. Fools don't take it."
-Benjamin Franklin
---------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: thinking Merlin/Pheoix stuff ...
Posted by Peter Donald <pe...@apache.org>.
Hi,
Cross-posting to avalon-dev as I believe that the Cocooners have notion of
scope as they can have sitemaps "mounted" in other sitemaps which is similar.
Thus they probably be able to explain their implementation.
On Wed, 5 Jun 2002 16:21, Stephen McConnell wrote:
> Peter Donald wrote:
> >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.
>
> Can you provide some relevant links (i.e. more relevant then the root
> myrmidon) so I can get a better feel for the implication of scopes?
Unfortunately most of the information is located in Adams head (another active
developer on myrmidon) so I am not sure I could explain it fully ;)
However the basic idea is as follows;
Each component lives in a "scope" or environment. For instance myrmidon has
components such as
* ConverterManager
* TypeManager
* Configurator
* Executor
Now for some of these components (TypeManager for instance) you can create
Child objects. The TypeManager child allows you to register extra types.
These types are visible to current TypeManager and all child TypeManagers
(unless they get overidden).
So lets say we have scopes;
* workspace
* project
* target
* task
* sub-tasks
If you register a type at workspace level then it will be visible to all tasks
in all projects. If you register type in one project (say via a taskdef) then
it will only be accessible by that project and not any other projects in
workspace.
This phenomenon can be nested as far as you want to go (ie tasks can create
their own scopes and execute child tasks inside them).
A naive implementation would have each service implement a createChildX method
if needed. However what happens when the Configurator depends on TypeManager
and a child TypeManager is created. This means a child Configurator has to be
created or an exception has to be thrown (or warning issued or whatever).
Anyways - what about mounted Cocoon sitemaps - are they similar?
--
Cheers,
Peter Donald
---------------------------------------------------
"Wise men don't need advice. Fools don't take it."
-Benjamin Franklin
---------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: thinking Merlin/Pheoix stuff ...
Posted by Stephen McConnell <mc...@osm.net>.
Peter Donald wrote:
>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.
>
Can you provide some relevant links (i.e. more relevant then the root
myrmidon) so I can get a better feel for the implication of scopes?
>
> - 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).
>
Yep.
>
> - 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.
>
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
>>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).
>
Yep.
>
>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.
>
Nested configuration trees is my prefered option - although I can manage
with any of the above (I'm just thinking ahead when yoiu want to get
into more complext constraints such as QoS).
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: thinking Merlin/Pheoix stuff ...
Posted by Peter Donald <pe...@apache.org>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: thinking Merlin/Pheoix stuff ...
Posted by Stephen McConnell <mc...@osm.net>.
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?
2. What approach are you using for supply constraints to the service
your creating?
Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: thinking Merlin/Pheoix stuff ...
Posted by Peter Donald <pe...@apache.org>.
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.
--
Cheers,
Peter Donald
-----------------------------------------------------------------------
| I thought there was a knob on the TV to turn up the intelligence. |
| There's a knob called "brightness", but it doesn't work. |
-----------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: thinking Merlin/Pheoix stuff ...
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Stephen McConnell" <mc...@osm.net>
> >- Leo, 41 hours without sleep and counting...nearing personal record...
> >
>
> Go fo 48 - thats when you start to loose control over finer-grain
> physical coordination :-)
>
Judging from my coordination now, I guess that the 48 hours don't need to be
consecutive ;-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: thinking Merlin/Pheoix stuff ...
Posted by Stephen McConnell <mc...@osm.net>.
>
>
>- Leo, 41 hours without sleep and counting...nearing personal record...
>
>
>
Go fo 48 - thats when you start to loose control over finer-grain
physical coordination :-)
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: thinking Merlin/Pheoix stuff ...
Posted by Leo Simons <le...@apache.org>.
> Nicola Ken Barozzi wrote:
>
> >Just 2 cents:
> >The name "kernel" has scared me in the past away from Phoenix, since it
> >reminds of operating systems and something reeeealy low level.
> >Apart from the real meaning, the semantics in the more "vulgar" world are a
> >bit different.
> >
>
> The word kernel had exactly the same impact on me way back when I first
> started looking under the covers of Phoenix.
One of the things that lured me into avalon. "What am I gonna learn
today, enterprise java or os development? Hmmm, this thing here has a
kernel, too...."
We could just call it "engine" though. Everyone loves cars, not?
- Leo, 41 hours without sleep and counting...nearing personal record...
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: thinking Merlin/Pheoix stuff ...
Posted by Stephen McConnell <mc...@osm.net>.
Nicola Ken Barozzi wrote:
>Just 2 cents:
>The name "kernel" has scared me in the past away from Phoenix, since it
>reminds of operating systems and something reeeealy low level.
>Apart from the real meaning, the semantics in the more "vulgar" world are a
>bit different.
>
The word kernel had exactly the same impact on me way back when I first
started looking under the covers of Phoenix.
Cheers, Steve.
>
>--
>Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
>---------------------------------------------------------------------
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: thinking Merlin/Pheoix stuff ...
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Just 2 cents:
The name "kernel" has scared me in the past away from Phoenix, since it
reminds of operating systems and something reeeealy low level.
Apart from the real meaning, the semantics in the more "vulgar" world are a
bit different.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: thinking Merlin/Pheoix stuff ...
Posted by Stephen McConnell <mc...@osm.net>.
Paul Hammant wrote:
> Stephen,
>
>> Hi Paul:
>>
>> I'll try to recap things (and I'm also posting this to the general
>> list because it is relevant to discussions concerning containers and
>> general lifecycle management).
>
>
> Thanks for that lengthy roll-up. Very valuable for newbies (to an
> issue) like me.
>
> I've read it and the following discussion between you and PeterD.
> Peter Royal's flash of inspiration looks interesting.
Yep - I have to dig some more into X-Path to fully get the implications.
> Even if it is not a 'third way' for this problem, then it will be
> useful for other things (at least for me). So I am a little clearer
> on terminology and the issues generated. Only a little though ;-).
>
> Terms
> ====
>
> Stephen's words (generalized ?) :
>
>> Where composer == Merline/Phoenix/...
>> Container == any composite component (e.g. an ORB)
>> Component == the thing declaring the dependecy constraints
>
>
> Peter Donald's (specialized ?):
>
>> 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
>
>
> I'm inclined to agree with Peter, however I think this is better :
>
> Component = thing declaring dependencies and that may be depended upon.
> Constraint = specialized information for a component's dependancies
I would rephrase this to say that a constraint is structure used to
qualify a depedency
>
> Kernel = Merlin/Phoenix/other that handles lifecycle management of
> components. May have multiple impls.
I prefer composer - because in my mind there is typically one kernel -
in the case of Phoenix this makes sence. In the case of Merlin it does
not make sence. However, I agree that the term kernal is appropriate
when we are talking about the thing executes the assembly and deployment
process. From this perspective, when you run Merlin from the commmand
line its executing in the role of a kernel. If you use Melin as a
component (e.g. via a dependency), then Merlin is more correctly
described as a composer.
>
> Container = thing hosting specialized components, using a kernel that
> may also be a composite component.
I should not have used the word "container" - I think I was up too long :-)
>
> Hmmm, maybe that is not so useful for this discussion. Maybe it is
> unnecessary term defining on my part.
Its relavant - because we imply lots of stuff in the word we use :-)
>
>
> Roll-up
> =======
>
> Could we have another. The discussion have moved on since the last.
> Maybe it is not so important to re-establish context again. Ideally
> something along the lines are
> Brief descr of goals / issue.
>
> Peter's current proposition with snippets of example code/xml
> Stephen's doubts with that
>
> Stephen's current proposition with snippets of example code/xml
> Peter's doubts with that.
>
> It will help my example-orientated (oriented ?) mind to understand
> what you guys are discusing. It might be that my input is not needed
> as you are charging off in healthy discussions quite well. Having
> said that, there are two kernel/comtainers that I am involved with
> that might benefit (Jesktop and EOB).
>
> - Paul
Hold this throught until after I've checked out the ContainerKit
meta-data stuff :-)
Cheers, Steve.
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: thinking Merlin/Pheoix stuff ...
Posted by Paul Hammant <Pa...@yahoo.com>.
Stephen,
> Hi Paul:
>
> I'll try to recap things (and I'm also posting this to the general
> list because it is relevant to discussions concerning containers and
> general lifecycle management).
Thanks for that lengthy roll-up. Very valuable for newbies (to an
issue) like me.
I've read it and the following discussion between you and PeterD. Peter
Royal's flash of inspiration looks interesting. Even if it is not a
'third way' for this problem, then it will be useful for other things
(at least for me). So I am a little clearer on terminology and the
issues generated. Only a little though ;-).
Terms
====
Stephen's words (generalized ?) :
> Where composer == Merline/Phoenix/...
> Container == any composite component (e.g. an ORB)
> Component == the thing declaring the dependecy constraints
Peter Donald's (specialized ?):
> 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
I'm inclined to agree with Peter, however I think this is better :
Component = thing declaring dependencies and that may be depended upon.
Constraint = specialized information for a component's dependancies
Kernel = Merlin/Phoenix/other that handles lifecycle management of components. May have multiple impls.
Container = thing hosting specialized components, using a kernel that may also be a composite component.
Hmmm, maybe that is not so useful for this discussion. Maybe it is unnecessary term defining on my part.
Roll-up
=======
Could we have another. The discussion have moved on since the last. Maybe it is not so important to re-establish context again. Ideally something along the lines are
Brief descr of goals / issue.
Peter's current proposition with snippets of example code/xml
Stephen's doubts with that
Stephen's current proposition with snippets of example code/xml
Peter's doubts with that.
It will help my example-orientated (oriented ?) mind to understand what you guys are discusing. It might be that my input is not needed as you are charging off in healthy discussions quite well. Having said that, there are two kernel/comtainers that I am involved with that might benefit (Jesktop and EOB).
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: thinking Merlin/Pheoix stuff ...
Posted by Stephen McConnell <mc...@osm.net>.
Paul Hammant wrote:
> Stephen, Peter,
>
> I just wanted to say, that I've read the entire thread, but can't say
> I completely understand what is being proposed and countered. I know
> that is not much help, but I think it right to illustrate that I've
> not ignored this call for greater mindshare.
>
Hi Paul:
I'll try to recap things (and I'm also posting this to the general list
because it is relevant to discussions concerning containers and general
lifecycle management).
Both Merlin and Phoenix use information from a .xinfo file to determine
the dependencies that a component has when building the container. In
addition to dependencies, both deal with the management of component
configurations and component assembly. However, Merlin and Phoenix
diverge in the way configuration and assembly information is managed.
Merlin enables the introduction a release configuration as something
separate from a deployment configuration. The release configuration is
static (only modified by a developer). The actual configuration instance
supplied to a component is a composite of the release and the deployment
configuration (via the CascadingConfiguration class) - so in effect the
site configuration can supplement/override a release configuration.
This makes it possible to supply components with pre-configured
configuration which in many cases need no modification and in the worst
case, maybe one or two declarations to customize a component for a
particular site. Merlin currently holds the release (default)
configuration in the <classname>.xinfo file. The current conclusion on
this topic is that this could be moved to a <classname>.xconfig file and
could be supported by both Merlin and Phoenix without problem.
The second area of assembly is more complicated. Merlin was created
with the specific objective of automatically running a target component
without the need for explicit specification of assembly information.
I.e. "take any component and just run it". In simple cases this is
possible based on the combination of dependency declarations and default
configurations. However, problems arise when the target component (T)
has a dependency on an assembled component (A) in that it must be able
to declare in the dependency statement that (A) can provide (x). In
practical terms, an application (T) has a dependency on an ORB (A) from
which it can get a time service (x). The dependency declaration model
we have only supports the declaration of the interface together with the
role name. What's missing is the ability to declare within a dependency
a declaration that the supplied service must meet a particular minimum
criteria to be considered as a viable service. Merlin's approach here
is to include a configuration fragment inside the dependency
declaration. During composition, that configuration fragment is added
to the configuration chain that is build up when preparing the dependent
component. The Phoenix approach is similar except that it has a level
of indirection ... the dependency declares a role, the assembly.xml
declares the mapping to a particular component configuration. The issue
is that Merlin's inclusion of a configuration fragment inside a
dependency declaration breaks compatibility with Phoenix.
All of this comes does to the fact that we don't have a mechanisms to
declare constraints within a dependency. Role and interface are not
sufficient - but introducing additional criteria needs to be considered
carefully because this must be resolvable by any container dealing with
any component. In effect, we (the Avalon community) have been handling
[micro] component assembly somewhat implicitly through configurations
(as distinct from [macro] assembly based on dependencies).
Somehow, we need the ability to say the following:
<dependencies>
<dependency>
<!-- declaration of a classic dependency -->
<role>orb</role>
<service name="org.apache.orb.ORB" version="2.4">
<!--
Plus something here that declares the minimum
criteria that the supplied service must meet
for it to be a satisfactory candidate.
-->
<assembly>
<!--
Anything in here is basically information
that is specific to the dependent service.
For example, in the case of an ORB this is
typically a set of interceptor declarations
that will result in the ORB composition with
a set of resolvable extensions needed by
this component.
-->
<initializer name="time"
class="org.apache.time.Initializer"/>
</assembly>
</service>
</dependency>
</dependencies>
Assuming that the <assembly> element was added as a valid child of a
<service> element - what should Phoenix and Merlin do with it?. The
current Merlin approach is to include this fragment as a part of the
configuration chain and everything works fine because it is up to the
ORB component to interpret these directives. On the other-hand, its not
so easy to do this within Phoenix without the introduction of either an
explicitly reserved element name in the configuration (undesirable), or,
the introduction of an additional lifecycle phase that differentiates
micro-assembly criteria from classic configuration content.
For example, consider the following:
if( service instance of Composite )
{
try
{
((Composite)service).assemble( criteria );
}
catch( CompositionException e )
{
// handle error
}
}
Such a phase would clearly come before initialization and probably
follow configuration, however, I not completly convinced that this is a
distinct phase (as opposed to a part of the process of initialization).
If internal [micro] assembly is part of an initialization phase, then
(a) the assembly constraint information must be supplied explicitly, or,
(b) assembly criteria must be resolvable from the supplied
configuration, or (c) assembly criteria must come in though the context
information.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: thinking Merlin/Pheoix stuff ...
Posted by Stephen McConnell <mc...@osm.net>.
Paul Hammant wrote:
> Stephen, Peter,
>
> I just wanted to say, that I've read the entire thread, but can't say
> I completely understand what is being proposed and countered. I know
> that is not much help, but I think it right to illustrate that I've
> not ignored this call for greater mindshare.
>
Hi Paul:
I'll try to recap things (and I'm also posting this to the general list
because it is relevant to discussions concerning containers and general
lifecycle management).
Both Merlin and Phoenix use information from a .xinfo file to determine
the dependencies that a component has when building the container. In
addition to dependencies, both deal with the management of component
configurations and component assembly. However, Merlin and Phoenix
diverge in the way configuration and assembly information is managed.
Merlin enables the introduction a release configuration as something
separate from a deployment configuration. The release configuration is
static (only modified by a developer). The actual configuration instance
supplied to a component is a composite of the release and the deployment
configuration (via the CascadingConfiguration class) - so in effect the
site configuration can supplement/override a release configuration.
This makes it possible to supply components with pre-configured
configuration which in many cases need no modification and in the worst
case, maybe one or two declarations to customize a component for a
particular site. Merlin currently holds the release (default)
configuration in the <classname>.xinfo file. The current conclusion on
this topic is that this could be moved to a <classname>.xconfig file and
could be supported by both Merlin and Phoenix without problem.
The second area of assembly is more complicated. Merlin was created
with the specific objective of automatically running a target component
without the need for explicit specification of assembly information.
I.e. "take any component and just run it". In simple cases this is
possible based on the combination of dependency declarations and default
configurations. However, problems arise when the target component (T)
has a dependency on an assembled component (A) in that it must be able
to declare in the dependency statement that (A) can provide (x). In
practical terms, an application (T) has a dependency on an ORB (A) from
which it can get a time service (x). The dependency declaration model
we have only supports the declaration of the interface together with the
role name. What's missing is the ability to declare within a dependency
a declaration that the supplied service must meet a particular minimum
criteria to be considered as a viable service. Merlin's approach here
is to include a configuration fragment inside the dependency
declaration. During composition, that configuration fragment is added
to the configuration chain that is build up when preparing the dependent
component. The Phoenix approach is similar except that it has a level
of indirection ... the dependency declares a role, the assembly.xml
declares the mapping to a particular component configuration. The issue
is that Merlin's inclusion of a configuration fragment inside a
dependency declaration breaks compatibility with Phoenix.
All of this comes does to the fact that we don't have a mechanisms to
declare constraints within a dependency. Role and interface are not
sufficient - but introducing additional criteria needs to be considered
carefully because this must be resolvable by any container dealing with
any component. In effect, we (the Avalon community) have been handling
[micro] component assembly somewhat implicitly through configurations
(as distinct from [macro] assembly based on dependencies).
Somehow, we need the ability to say the following:
<dependencies>
<dependency>
<!-- declaration of a classic dependency -->
<role>orb</role>
<service name="org.apache.orb.ORB" version="2.4">
<!--
Plus something here that declares the minimum
criteria that the supplied service must meet
for it to be a satisfactory candidate.
-->
<assembly>
<!--
Anything in here is basically information
that is specific to the dependent service.
For example, in the case of an ORB this is
typically a set of interceptor declarations
that will result in the ORB composition with
a set of resolvable extensions needed by
this component.
-->
<initializer name="time"
class="org.apache.time.Initializer"/>
</assembly>
</service>
</dependency>
</dependencies>
Assuming that the <assembly> element was added as a valid child of a
<service> element - what should Phoenix and Merlin do with it?. The
current Merlin approach is to include this fragment as a part of the
configuration chain and everything works fine because it is up to the
ORB component to interpret these directives. On the other-hand, its not
so easy to do this within Phoenix without the introduction of either an
explicitly reserved element name in the configuration (undesirable), or,
the introduction of an additional lifecycle phase that differentiates
micro-assembly criteria from classic configuration content.
For example, consider the following:
if( service instance of Composite )
{
try
{
((Composite)service).assemble( criteria );
}
catch( CompositionException e )
{
// handle error
}
}
Such a phase would clearly come before initialization and probably
follow configuration, however, I not completly convinced that this is a
distinct phase (as opposed to a part of the process of initialization).
If internal [micro] assembly is part of an initialization phase, then
(a) the assembly constraint information must be supplied explicitly, or,
(b) assembly criteria must be resolvable from the supplied
configuration, or (c) assembly criteria must come in though the context
information.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: thinking Merlin/Pheoix stuff ...
Posted by Paul Hammant <Pa...@yahoo.com>.
Stephen, Peter,
I just wanted to say, that I've read the entire thread, but can't say I
completely understand what is being proposed and countered. I know that
is not much help, but I think it right to illustrate that I've not
ignored this call for greater mindshare.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: thinking Merlin/Pheoix stuff ...
Posted by Stephen McConnell <mc...@osm.net>.
Peter Donald wrote:
>On Fri, 31 May 2002 17:59, Stephen McConnell wrote:
>
>>Looking at a real example - the assembly of an ORB - the information
>>supplied to an ORB to assemble itself is specific to an ORB component.
>> As shown in the above example, its a bunch of interceptor declarations.
>>
>
>The problem is that there is no way that I can think of of passing in
>configuration without restricting yourself to a particular implementation.
>For instance most roles/interfaces can have multiple implementations.
>
>One implementation may require configuration, one may not require
>configuration (it may be fixed at compile time), one configuration schema may
>be different from another. One implementation may have similar contained
>components but represented completely and utterly differently or whatever. ie
>Are interceptors specific to OpenORB implementation? or are they generic
>across all Corba ORBs?
>
An interceptor is a standard ORB extension mechanisms. In fact you can
look at an ORB as a ServiceManager - interceptors represent service
available via the ORB. In the classic ORB specificiation these are
accessed via orb.resolve_initial_references( "myService" ). The
org.apache.orb.ORB implementation actually implements the ServiceManager
interface which simply delegates actions to the standard
resolve_initial_references operation.
Using the example we discussed before of a component that has a
dependecy on an ORB from which it can locate a time service ... if we
translate this into Avalon terminaology, it could be described as a
component that has a dependecy on a service (which is a ServiceManager)
that exposes sub-services. If the dependency declaration were extended
to support nested dependencies, we could potentially see something like
the following:
<dependencies>
<dependency>
<!-- declaration of a classic dependency -->
<role>orb</role>
<service name="org.apache.orb.ORB" version="2.4">
<!-- declaration of the nested dependecies that this
component has on the supplied ORB -->
<dependency>
<role name="time">
<service name="org.omg.CosTime.TimeService" version="1.0">
</dependecy>
</service>
</dependency>
</dependencies>
When handling the establishment of the component, a container can spot
the nested dependecies and recognize that this menas that the primary
dependecy is a service manager that has to be populated relative to the
sub-dependencies. This would get out out of the "configuration" issue
and focussed on the question of nested dependecy declarations.
The actual component could then do something like:
public void service( ServiceManager manager )
{
m_orb = (ORB) manager.lookup( "orb" );
m_time = (TimeService) manager.lookup( "orb/time" );
}
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>