avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: [migration] questions on the roles file
Date Thu, 04 Mar 2004 14:05:51 GMT
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.

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

> 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?

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

> 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?

THanks
Carsten


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


Mime
View raw message