avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@osm.net>
Subject Re: Phoenixs Deprecated features
Date Sat, 11 May 2002 23:31:02 GMT

Peter Donald wrote:

>On Sat, 11 May 2002 12:07, Stephen McConnell wrote:
>>No problem with any of the proposed changes.
>>I would like to see addition of support for CascadingConfigurations
>>together with the addition of extensions to the .xinfo file to contain a
>>default confituation declararation (which would bring Phoenix and Merlin
>>almost totally in sync). Any thoughts about how this can be achieved?
>A few. Currently I am working on trying to get decent interoperability between 
>Merlin, Fortress, ECM, Phoenix and Myrmidon. While each container has 
>slightly different needs there is also a bunch of common ground. Currently 
>the main things I am interested is getting together a single representation 
>of component meta data.
>The types of component meta data I am thinking of is mainly;
>* lifecycle "style": Is it poolable, is it re-entrant, is it threadsafe, is 
>singlethreaded etc
Just a note that I think that we will sooner or later have to deal with 
the pooled concept at the framework - by the addition of a specific 
interface for a Pool, or, elimination of pooling notions at the level of 
ServiceManager and ComponentManager.

>* context: 
>   - Context Class
>   - Entrys in Context (both name of entry and type of entry)
I'm assuming you mean something along the lines of 
org.apache.excalibur.context.ContextUtility (which I'm using within 
Merlin).  It handes the above but the javadoc really needs some work.

>* service:
>   - services required by component 
>* configuration/parameters:
>   - schema+validaiton of Configuration/Parameters
>In each different container the info is represented differently. However what 
>I was thinking of was developing a set of standard javadoc tags and 
>processing the sourcefile using the XDoclet tool available at;
>This tool would generate the manifest files, blockinfos, possibly default 
>configurations and so forth in context of Phoenix/Merlin. 
This is probably the asiest first step.

>With a different template you could use XDoclet to generate the descriptor 
>files for Fortress/ECM/Myrmidon.
>> Inital ideas are either (a) implict addition of default configuration
>>handling within Phoenix, or (b) the ability to declare an
>>alternative/pluggable configuration resolver.
>Technically is possible now. I could even add in plugin points to the deployer 
>if you really want this right away (And you could just create a custom 
>MerlinDeployer that uses CascadingConfiguration). 
>I was going to try address it in a global manner first but if you want me to 
>make it possible for you to overide default behaviour with 
>CascadingConfigurerr then it should be relatively easy. Just say the word.
Before answering the above, I'll go into a more detail concerning Merlin 
configuration semantics.  First of all - the import differences between 
Merlin and Phoenix is that Merlin's support for assembly is much more 
limited than Phoenix - but the other side of the coin is that it handles 
component assembly and execution without the overhead of assembly.xml, 
environment.xml, etc.  Merlin achieves this through extensive 
application of cascading configuration information. For a top-level 
target component Merlin is the container.  The target configuration is 
created based on the following:

      (primary)                   (parent)
  <configuration-file>   <target-xinfo.configuration>
          |                         |

Based on the dependencies declared in the .xinfo file, the container 
creates and populates a service manager (or component manager) using the 
following cascading configuration schema:

            (primary)                          (parent)
 <container.dependency.configuration>  <dependent-xinfo.configuration>
               |                                 |
           (primary)                  (parent)
  <target-configuration.role>  <dependant-configuration>
             |                           |

The above graph assumes two extensions to the Phoenix .xinfo  schema.  
Firstly, there is the usage of a <configuration> declared as a child of 
the <block> element (typically used to hold release related 
configuration info (as distinct from deployment configuration info).  
Secondly, Merlin looks for a <configuration> element declared within a 
dependency declaration and uses this in the construction of a 
configuration chain for the dependent service. The overriding principal 
is that this collection of information should enable the complete 
establishment of a component and that the level of site configuration 
should be very small if not totally eliminated.

Example .xinfo file:

The dramtically simplifies site confugration and lets me seperate relase 
configuration from deployment configuration (i.e. I put release 
configuration in the .xinfo and deployment configuration in a seperate 
modifyable configuration file).  The second area that I've been playing 
around with is the inclusion of a configuration element within a 
dependency declaration.  The purpose of this is to declare the default 
configuration profile for role.



  <block name="my-service">

      <service name="net.osm.HelloService" version="1.0" />

      <service name="net.osm.directory.DirectoryProvider" version="2.4"/>
         This contains a configration elements that are used
         to ensure that the dependent service is appropriately
         configurared.  For example, the HelloService may need
         an orb that is preconfigurated with a POA and
         NamingService - as such, the configuration elements
         included here can be considered as constraints applied
         by the HelloService that must be fulfilled by its

    This configuration element contains the default configuration
    for the component.

For completeness, there are two other .xinfo additions that should be 
noted.  Firstly, there is the introduction of the name attribute on the 
block element.  This is used to establish the name to assign to a 
logging channel for the root component.  Secondly, Merlin supports a 
<context> declarations within a .xinfo which is handled by the 
ContextUtility class.

Cheers, Steve.


Stephen J. McConnell

digital products for a global economy

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