avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: [migration] questions on the roles file
Date Thu, 04 Mar 2004 15:24:05 GMT
Carsten Ziegeler wrote:

> Stephen McConnell wrote: 
> 
>>Take two!
>>
> 
> :)
> 
> 
>>The ECM Scenario
>>----------------
>>
>>Here is a ECM/Fortress style <role> element.
>>
>>  <role name="org.apache.cocoon....PortalManager"
>>      shorthand="portal-manager"
>>      default-class="org.apache.cocoon....PortalManagerImpl"/>
>>
>>Here is a Merlin style component element:
>>
>>  <component name="portal-manager"
>>    class="org.apache.cocoon....PortalManagerImpl"/>
>>
> In addition you can use the Merlin style component element in
> the configuration file with ECM/Fortress as well. Cocoon uses
> both.
> 
> 
>>In Cocoon (please correct any mistaken assumptions) the 
>>client application (i.e. the site-map parser) reads in 
>>requests for services and invokes requests on an object 
>>implementing the ComponentManager interface (e.g. ECM).
>>
>>   Component component =
>>     m_manager.lookup( PortalManager.class.getName() );
>>
> 
> Yes, we nearly moved all parts (where we could) to ServiceManager.
> Starting with 2.2 we will only be using ServiceManager.

This is good news - removes a problem off the table.

>>The ECM implementation locates a role entry based on the 
>>interface name, maps that to a implementation class (based on 
>>the role and/or config attributes), maps the implementation 
>>class to a handler and returns an instance from the handler.
>>
> 
> Perhaps we are meaning the same, but for safety I describe how
> I think it works. The lookup uses a role which is just a name.
> In most cases it's the interface name of the component to
> lookup but that's not required.

Assuming we have this <role> declaration:

   <role name="org.apache.cocoon....PortalManager"
       shorthand="portal-manager"
       default-class="org.apache.cocoon....PortalManagerImpl"/>

Are you saying that the String passed to lookup is simply the value of 
the "name" attribute?

> This role name is searched in the roles config, the implementation
> class is found, mapped to a handler and an instance is returned
> from the handler.
> In addition, the central configuration file is searched first,
> as there could either be a <component name= class= definition
> or the default implementation in the roles file could be overwritten
> there using the shorthand: <portal-manager class="org.package.AnotherImpl"/>
> The configuration has precedence over the roles.

Yep - were on the same track (or at least heading in the same 
direction).  One question - if the role name attribute is the lookup 
key, what is the logic for identifying the service interface(s) that 
should be returned from the lookup operation?

E.g. consider the following:

   <role name="widget"
       shorthand="portal-manager"
       default-class="org.apache.cocoon....PortalManagerImpl"/>

In the case I have to shorthand name which lets me resolve the class 
from the configs and I have the lookup key.  But I'm missing the 
declaration of the services that the component class is providing.


>>The Merlin Scenario
>>-------------------
>>
>>In Cocoon the client application (i.e. the site-map parser) 
>>reads in requests for services and invokes requests on an 
>>object implementing the ServiceManager interface (e.g. ecm-facility).
>>
>>   Object service =
>>     m_manager.lookup( PortalManager.class.getName() );
>>
>>The ecm-facility implementation locates a component model 
>>implementing the service class and returns this to the 
>>invoking client.  At this stage we don't need any role file 
>>or configuration.  In fact all we need is an empty container 
>>with a classloader declaration (example available in the 
>>merlin/platform/tutorials/dynamics tutorial in CVS).  
> 
> And the implementation for the role is detected by the meta-info
> contained in the jars, right?

Correct.

Each component type declares in an xinfo file the service it can provide 
(and its dependencies).  This information is used to construct a 
descriptor called a Type.  Merlin maintains a registry per container of 
the available types and the profiles available for each type.

> 
> 
>>However 
>>- just pulling in implementations isn't enough - sometimes we 
>>need to parameterize the solution.  In ECM/Fortress this is 
>>referred to as a role.  In Merlin it is referred to as a 
>>profile.  Based on the information in existing roles and 
>>config file we should be able to automatically generate a 
>>block definition.
>>
>>The above process will work fine for components that are 
>>written for ServiceManager and are accompanied by xinfo 
>>files. Without the xinfo we would need to either put in place 
>>xinfo generator for ECM style components or handle dynamic 
>>Type registration based on reading in a role file.
>>
>>The above scenario sort of looks like the following:
>>
>>   |--------------------------|                  |-----------------
>>   |  Merlin                  |     exports      | Cocoon
>>   |                          |  ServiceManager  |
>>   |  <container> ------------|----------------->|
>>   |   <ecm-facility>         |                  |
>>   |   <classic-component>    |
>>   |   <classic-component>    |
>>   |   <generated-component>  |
>>   |                          |
>>   |
>>
> 
> Sorry, but I lost you, can you explain this a little bit more. Please
> keep in mind that I know nearly nothing of Merlin.

No problem.  First off I'll explain what I mean by "facility", 
"classic-component" and "generated-component".

   1. classic-component, this is a pure 100% typical merlin
      merlin component - bundled with meta-info, may also have
      its own static configuration and possible bundled profiles
      describing how it should be deployed (configuration etc.)

   2. facility, a facility is a privileged component that is
      granted access to the meta-model - accessing the meta model
      means that the facility can do things like:

        * modify existing component models
        * and and remove component and container models
        * deploy and decommission components
        * initiate reassembly of a node in the container
          hierarchy

   3. generated component - this is basically a component model
      that is created programatically (as opposed to creation via
      a <component> directive) - to create a generated facility
      you would need to write a facilities

The approach I'm thinking about is a ECM facility.  I.e. a component 
with privileged access to the meta model that can dynamically create and 
tear-down component models as required. The service provided by this 
facility and visible to the cocoon client would be the ServiceManager 
interface.  The implementation would serve two functions:

   a). interaction with classic merlin components as required

   b). automate the dynamic generation of components based on legacy
       content (role files, marker interfaces, etc.)

This would enable progressive migration because you would be able to 
have normal merlin components mixed in with ECM components (because both 
would be represented using the same meta-model).  In effect - the ECM 
facility is acting as a model controller that deals with adapting to two 
different component models and presenting a unified view to the cocoon 
client.  Progressively ECM components could be migrated without "stress".

>>One thing to keep in mind in the above is that none of this 
>>requires any change to merlin internals.  The complete set of 
>>ECM semantics are handled by the ecm-facility (which is a 
>>component running in merlin exporting a service that just 
>>happens to be the ServiceManager interface from framework).  
>>This is nice because we can isolate the ECM style logic while 
>>maintaining ability to evolve.
>>
>>Before going further into the "ComponentManager versus 
>>ServiceManager" 
>>and "Selector" questions - how is this looking so far?
>>
> 
> 
> Sorry, as stated above, I didn't get it.
> 
> I see one potential problem: most components that are used
> with ECM/Fortress don't have any meta-information and they
> must still run without adding this extra information to
> the classes. So a binary compatiblity is required.
> Does this work?

In principal this is the job of the ECM-facility (perhaps aided by a 
tool).  It would need to recognize ECM components and programatically 
construct a Type definition and deployment profile either at startup, on 
demand, or at some prior event via a pre-processor.  From here on the 
facility is interacting with the merlin meta model in the same way for 
all components (irrespective of their source or migration status).

I know I'm going kind of deep here but I'm kind of thinking this out for 
myself as I go along.

:-)

Cheers, Stephen.


> THanks
> Carsten
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
> 
> 


-- 

|------------------------------------------------|
| Magic by Merlin                                |
| Production by Avalon                           |
|                                                |
| http://avalon.apache.org/merlin                |
| http://dpml.net/merlin/distributions/latest    |
|------------------------------------------------|

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message