Return-Path: Delivered-To: apmail-avalon-dev-archive@www.apache.org Received: (qmail 55979 invoked from network); 4 Mar 2004 15:20:58 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 4 Mar 2004 15:20:58 -0000 Received: (qmail 98500 invoked by uid 500); 4 Mar 2004 15:20:52 -0000 Delivered-To: apmail-avalon-dev-archive@avalon.apache.org Received: (qmail 98454 invoked by uid 500); 4 Mar 2004 15:20:52 -0000 Mailing-List: contact dev-help@avalon.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon Developers List" Reply-To: "Avalon Developers List" Delivered-To: mailing list dev@avalon.apache.org Received: (qmail 98431 invoked from network); 4 Mar 2004 15:20:51 -0000 Received: from unknown (HELO smtp.noos.fr) (212.198.2.122) by daedalus.apache.org with SMTP; 4 Mar 2004 15:20:51 -0000 Received: (qmail 28030 invoked by uid 0); 4 Mar 2004 15:20:51 -0000 Received: from unknown (HELO apache.org) ([212.198.17.4]) (envelope-sender ) by 212.198.2.122 (qmail-ldap-1.03) with SMTP for ; 4 Mar 2004 15:20:51 -0000 Message-ID: <40474A15.2060804@apache.org> Date: Thu, 04 Mar 2004 16:24:05 +0100 From: Stephen McConnell User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Avalon Developers List Subject: Re: [migration] questions on the roles file References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Carsten Ziegeler wrote: > Stephen McConnell wrote: > >>Take two! >> > > :) > > >>The ECM Scenario >>---------------- >> >>Here is a ECM/Fortress style element. >> >> > shorthand="portal-manager" >> default-class="org.apache.cocoon....PortalManagerImpl"/> >> >>Here is a Merlin style component element: >> >> > 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 declaration: 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 or the default implementation in the roles file could be overwritten > there using the shorthand: > 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: 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 | >> | ------------|----------------->| >> | | | >> | | >> | | >> | | >> | | >> | >> > > 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 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