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 12:51:44 GMT
Stephen McConnell wrote:

> Steve has just hit a reset button and it going to dig some more.
> Thanks for the feedback.

Take two!

The ECM Scenario

Here is a ECM/Fortress style <role> element.

  <role name="org.apache.cocoon....PortalManager"

Here is a Merlin style component element:

  <component name="portal-manager"

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() );

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.

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

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?



| 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

View raw message