You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Stephen McConnell <mc...@apache.org> on 2004/03/04 01:10:07 UTC
[migration] questions on the roles file
From the Cocoon CVS:
<xroles xpath="/role-list"
unless="role[@name='org.apache.cocoon.webapps.portal.components.PortalManager']">
<role name="org.apache.cocoon.webapps.portal.components.PortalManager"
shorthand="portal-manager"
default-class="org.apache.cocoon.webapps.portal.components.PortalManagerImpl"/>
</xroles>
Some questions:
1. is there a formal specification of the <xroles> element somewhere?
2. presumably the "xpath" attribute combined with the "unless" attribute
represent a precondition to service selection - it that correct?
3. the <role> element represents a request for a service and the service
interface is declared under the name attribute
4. the <role> shorthand attribute is a pointer into a config file for
the component configuration
5. default-class attribute identifies a class, but it's name implies
that is not necessarily what is returned
Some observations:
The above looks to me like the declaration of two things mixed together.
1. Firstly there is the expression of a requirement for
a service using a model that enables conditional
expressions.
2. Secondly the role element appears to be mapping a
candidate service to a candidate implementation class
together with a configuration reference
Some initial thoughts:
The above approach simply does not translate to the logic used in
Merlin. Under Merlin you would do something like:
<component name="portal-manager"
class="org.apache.cocoon....PortalManagerImpl">
<configuration>
<!-- whatever is in the config file with an
element named shorthand -->
</configuration>
</component>
But this is kind of academic because in Merlin is you request a service
Merlin will auto-locate it for you using meta info. So what we can do
is go back to the original declaration and try to separate the request
and solution information. I've left out the "unless" clause because (a)
I don't know what the expression means, and (b) it smells of
implementation specifics (but we can revisit that). Here is a
configuration fragment that seems to me to reflect the same thing:
<xroles xpath="/role-list">
<select>portal-manager</select>
</xroles>
So moving on - how does the above fragment relate to merlin. Currently
in merlin you can select a component that will provide a service by
referencing its address. The address is simply a sequence of container
names ending with the component name - e.g. /xxx/yyy/my-component.
However, that is not sufficient for what you want to to here. You need
to be able to establish a component that is doing query resolution based
on a supplied configuration argument (assuming I'm interpreting this
correctly).
For example:
<component name="xpath"
class="org.apache.cocoon....XPathProcessor"/>
The XpathProcessor component would be responsible for evaluating the
xpath expression and interacting with the container model to select the
appropriate component model and return a service instance from that model.
Am I on the right track here?
Stephen.
--
|------------------------------------------------|
| 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
RE: [migration] questions on the roles file
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stephen McConnell wrote:
>
>
> >>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?
>
Yes.
> > 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.
>
Yes, that is missing. It's a convention that the role name should be
the interface name. In addition the interface contains in most
cases the role name as a String:
interface PortalManager {
String ROLE = PortalManager.class.getName();
...
}
I have to leave right now, so I will take my time to read the
rest and answer then :)
Thanks
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [migration] questions on the roles file
Posted by Stephen McConnell <mc...@apache.org>.
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
RE: [migration] questions on the roles file
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
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
Re: [migration] questions on the roles file
Posted by Stephen McConnell <mc...@apache.org>.
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"
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 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?
Stephen.
--
|------------------------------------------------|
| 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
Re: [migration] questions on the roles file
Posted by Stephen McConnell <mc...@apache.org>.
Carsten Ziegeler wrote:
>>Am I on the right track here?
>
>
> I think: no :)
Me too!
> Actually, I see no real difference (but perhaps
> I'm wrong as well).
> With ECM
> you split the configuration into two parts: the roles definition
> in a separate file: this defines all the available components
> or services.
> And the configuration of each component (using the shorthand)
> in another file.
Steve has just hit a reset button and it going to dig some more.
Thanks for the feedback.
Steve.
--
|------------------------------------------------|
| 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
RE: [migration] questions on the roles file
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stephen McConnell wrote:
>
>From the Cocoon CVS:
>
> <xroles xpath="/role-list"
> unless="role[@name='org.apache.cocoon.webapps.portal.component
> s.PortalManager']">
> <role
> name="org.apache.cocoon.webapps.portal.components.PortalManager"
> shorthand="portal-manager"
> default-class="org.apache.cocoon.webapps.portal.components.Por
talManagerImpl"/>
> </xroles>
>
> Some questions:
>
> 1. is there a formal specification of the <xroles> element somewhere?
> 2. presumably the "xpath" attribute combined with the
> "unless" attribute represent a precondition to service
> selection - it that correct?
The above is not the cocoon roles file but a "patch" file that is merged
into the cocoon roles file. The format of the roles file is:
<?xml version="1.0"?>
<!DOCTYPE role-list [
<!ELEMENT role-list (role+)>
<!ELEMENT role (hint*)>
<!ELEMENT hint EMPTY>
<!ATTLIST role name CDATA #REQUIRED
shorthand CDATA #REQUIRED
default-class CDATA #IMPLIED
>
<!ATTLIST hint shorthand CDATA #REQUIRED
class CDATA #REQUIRED
>
]>
You find this file in src/java/org/apache/cocoon with the name cocoon.roles.
So the above is a file that is picked up by the build system and merged
into the cocoon.roles. It first tests if the fragment has already been
inserted etc.
> 3. the <role> element represents a request for a service and
> the service interface is declared under the name attribute
Yes.
> 4. the <role> shorthand attribute is a pointer into a config
> file for the component configuration
Yes, you can use either the role name or the shorthand to configure
the service.
> 5. default-class
> attribute identifies a class, but it's name implies that is
> not necessarily what is returned
>
Yes, this is the default implementation and can be overwritten
in the central configuration file (using the shorthand again)
> Some observations:
>
> The above looks to me like the declaration of two things
> mixed together.
>
> 1. Firstly there is the expression of a requirement for
> a service using a model that enables conditional
> expressions.
>
> 2. Secondly the role element appears to be mapping a
> candidate service to a candidate implementation class
> together with a configuration reference
>
> Some initial thoughts:
>
> The above approach simply does not translate to the logic
> used in Merlin. Under Merlin you would do something like:
>
> <component name="portal-manager"
> class="org.apache.cocoon....PortalManagerImpl">
> <configuration>
> <!-- whatever is in the config file with an
> element named shorthand -->
> </configuration>
> </component>
>
> But this is kind of academic because in Merlin is you request
> a service Merlin will auto-locate it for you using meta info.
> So what we can do is go back to the original declaration and
> try to separate the request and solution information. I've
> left out the "unless" clause because (a) I don't know what
> the expression means, and (b) it smells of implementation
> specifics (but we can revisit that). Here is a configuration
> fragment that seems to me to reflect the same thing:
>
> <xroles xpath="/role-list">
> <select>portal-manager</select>
> </xroles>
>
> So moving on - how does the above fragment relate to merlin.
> Currently in merlin you can select a component that will
> provide a service by referencing its address. The address is
> simply a sequence of container names ending with the
> component name - e.g. /xxx/yyy/my-component.
> However, that is not sufficient for what you want to to here.
> You need to be able to establish a component that is doing
> query resolution based on a supplied configuration argument
> (assuming I'm interpreting this correctly).
>
> For example:
>
> <component name="xpath"
> class="org.apache.cocoon....XPathProcessor"/>
>
> The XpathProcessor component would be responsible for
> evaluating the xpath expression and interacting with the
> container model to select the appropriate component model and
> return a service instance from that model.
>
> Am I on the right track here?
I think: no :) Actually, I see no real difference (but perhaps
I'm wrong as well).
With ECM
you split the configuration into two parts: the roles definition
in a separate file: this defines all the available components
or services.
And the configuration of each component (using the shorthand)
in another file.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org