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 2002/08/23 14:58:26 UTC
lookup semantics
As part of the work on Fortress/Merlin and an in the context of Cocoon
requirements, I'm starting to think about the best way to handle the
different semantic models related to the lookup operation on CM/SMs.
Current Status
--------------
* ECM/Fortress style
The CM/SM implementation treats the supplied string as
the classname of a component interface. It also allows
certain suffix values such as ...Selector. The selector
suffix is interpreted during the lookup resolution resulting
in a selector implementation reference returned to the client.
* Merlin/Phoenix style
The string argument supplied to the CM/SM is resolved against
a table of role names, mapped to component implementations.
No support is provided for the Selector suffix.
Possible Approaches
-------------------
There are several possible approaches to resolving this issue:
* Attribute Driven (Type Level)
Imagine that a type declared something like a
avalon:lookup-scope policy in its meta-info attribute set.
This policy value could be set to indicate if scope of
lookup is VM wide or constrained to the component type
(ECM versus Merlin semantics).
- advantages, relatively easy to implement
- disadvantages, scope is at the level of a component
so the mixing of both style in a single component
is compromised
* Attribute Driven (Dependency Level)
Similar to above, but the attribute is associated with
the dependency. The lookup operation would consider the
supplied string as a locally scoped key, and the policy
would determine if the container handler selection of the
implementation delegated selection to the client.
- advantages, mixes both scopes within a single component
- disadvantages, requires all ECM style components to
declare a formal meta-info model (which is a good thing, but is
practical/achievable)
* A new Lifecycle Interface
If we were to assume that the lookup operation was
restricted to locally scoped names (role name to service
provider mapping), we could image a separate interfaces
through which non-local service requests are resolved.
Such an interface could be something like:
public interface Locator
{
public Object locate( String role );
}
- advantages, clear separation of concerns with respect
to the different semantic models, relatively strait-
forward migration strategy for ECM style components,
easy to implementation within containers
- disadvantages, a new lifecycle interface (which is not
something to be consider lightly)
- notes, could be handled as an lifestyle extension
My own preference would be to kick-off some trials using a Locator
interface implemented as a Creator extension class.
Any thoughts ?
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: lookup semantics
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
>>From: Stephen McConnell [mailto:mcconnell@apache.org]
>>
>>Berin Loritsch wrote:
>>
>>
>>>What difference is there between this and the ...Locator
>>>class we proposed for A5?
>>>
>>>
>>>
>
><snip/>
>
>
>
>
>>The difference is that I'm isolating semantics and saying that:
>>
>>
>> a) a ServiceManager.lookup( ... ) handles the role argument as
>> a key within the scope of the component - i.e. doing a lookup
>> with an interface class name or a "Selector" would be
>>meaningless
>> (and would generate a ServiceException becuase it is
>>unknown in
>> the components role to service map)
>>
>> b) a ServiceLocator.locate( ... ) handles resolution of services
>> based on a supplied interface class name and handles
>>"Selector"
>> semantics. It does not know anything about the
>>notion of scoped
>> keys - its pure ECM/Fortress style lookup management.
>>
>>Two different semantics, two different interfaces.
>>
>>
>
>I see. Then why not have ServiceManager use the old style Fortress/ECM
>lookups (and why not? that is the way all the docs describe in
>Framework).
>The new ServiceLocator would use the new Merlin/Phoenix semantics.
>
>
>I mean if you are introducing semantics that current users are not used
>to, why force them to change their lookup mechanism just to keep the old
>semantics? I prefer the following approach (if we go down this path):
>
>Old semantics == Old lookup mechanism
>New semantics == New lookup mechanism
>
This makes sense.
I'm quite ok with the idea of ServiceManager.lookup( ... ) semantics being
associated with a non-component scoped resolve mechanism and ServiceLocator
directed to component scoped lookup. It would be strait forward to
implement.
>
>
>
>*** Oh, and expect an uphill battle getting it into framework as it is
> jealously guarded.
>
>
Gosh ... really?
;-)
>
>
>>>The ...Locator is essentially a replacement for
>>>
>>>
>>SeviceManager, at least
>>
>>
>>>as far as I can tell. I don't really see any compelling
>>>
>>>
>>reason to make
>>
>>
>>>that move *now*.
>>>
>>>
>>I'm not thinking about anything to do with A5 (in fact the
>>further away
>>A5 drifts the better as far as I am concered). What I'm
>>focssing on is
>>the seperation of quite different semantics that are currently in use
>>across one interface (which is BAD, BAD, BAD). This difference in
>>interpritation in a weakness in the framework that can be
>>addressed by
>>seperating the concerns - and should be addressed as part of A4. I'm
>>basically looking for a way to provide a clean and consitent
>>approach to
>>ECM/Fortress/Cocoon service location within the scope of a formal
>>structured meta driven framework.
>>
>>
>
>As I said above:
>
>
>Old semantics == Old lookup mechanism
>New semantics == New lookup mechanism
>
Yep - makes a lot of sense.
Cheers, Steve.
>
>I do agree that the difference in semantics is bad.
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: lookup semantics
Posted by Berin Loritsch <bl...@apache.org>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> Berin Loritsch wrote:
> >
> >What difference is there between this and the ...Locator
> >class we proposed for A5?
> >
<snip/>
> The difference is that I'm isolating semantics and saying that:
>
>
> a) a ServiceManager.lookup( ... ) handles the role argument as
> a key within the scope of the component - i.e. doing a lookup
> with an interface class name or a "Selector" would be
> meaningless
> (and would generate a ServiceException becuase it is
> unknown in
> the components role to service map)
>
> b) a ServiceLocator.locate( ... ) handles resolution of services
> based on a supplied interface class name and handles
> "Selector"
> semantics. It does not know anything about the
> notion of scoped
> keys - its pure ECM/Fortress style lookup management.
>
> Two different semantics, two different interfaces.
I see. Then why not have ServiceManager use the old style Fortress/ECM
lookups (and why not? that is the way all the docs describe in
Framework).
The new ServiceLocator would use the new Merlin/Phoenix semantics.
I mean if you are introducing semantics that current users are not used
to, why force them to change their lookup mechanism just to keep the old
semantics? I prefer the following approach (if we go down this path):
Old semantics == Old lookup mechanism
New semantics == New lookup mechanism
*** Oh, and expect an uphill battle getting it into framework as it is
jealously guarded.
> >The ...Locator is essentially a replacement for
> SeviceManager, at least
> >as far as I can tell. I don't really see any compelling
> reason to make
> >that move *now*.
>
> I'm not thinking about anything to do with A5 (in fact the
> further away
> A5 drifts the better as far as I am concered). What I'm
> focssing on is
> the seperation of quite different semantics that are currently in use
> across one interface (which is BAD, BAD, BAD). This difference in
> interpritation in a weakness in the framework that can be
> addressed by
> seperating the concerns - and should be addressed as part of A4. I'm
> basically looking for a way to provide a clean and consitent
> approach to
> ECM/Fortress/Cocoon service location within the scope of a formal
> structured meta driven framework.
As I said above:
Old semantics == Old lookup mechanism
New semantics == New lookup mechanism
I do agree that the difference in semantics is bad.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: lookup semantics
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
>>From: Stephen McConnell [mailto:mcconnell@apache.org]
>>
>>As part of the work on Fortress/Merlin and an in the context
>>of Cocoon requirements, I'm starting to think about the best
>>way to handle the different semantic models related to the
>>lookup operation on CM/SMs.
>>
>>Current Status
>>--------------
>>
>> * ECM/Fortress style
>>
>> The CM/SM implementation treats the supplied string as
>> the classname of a component interface. It also allows
>> certain suffix values such as ...Selector. The selector
>> suffix is interpreted during the lookup resolution resulting
>> in a selector implementation reference returned to the client.
>>
>> * Merlin/Phoenix style
>>
>> The string argument supplied to the CM/SM is resolved against
>> a table of role names, mapped to component implementations.
>> No support is provided for the Selector suffix.
>>
>>
>
>At the current moment, this will have to do. We want to allow
>users to get rid of their dependency on ...Selector. The Fortress
>approach allows that to happen, but we want to discourage the
>use of the ...Selector as much as possible.
>
>
>
>
>>Possible Approaches
>>-------------------
>>
>>There are several possible approaches to resolving this issue:
>>
>> * Attribute Driven (Type Level)
>>
>> Imagine that a type declared something like a
>> avalon:lookup-scope policy in its meta-info attribute set.
>> This policy value could be set to indicate if scope of
>> lookup is VM wide or constrained to the component type
>> (ECM versus Merlin semantics).
>>
>> - advantages, relatively easy to implement
>> - disadvantages, scope is at the level of a component
>> so the mixing of both style in a single component
>> is compromised
>>
>>
>
>-1 The Fortress approach is good enough, and this doesn't provide
> anything really different. We want to replace the ...Selector
> with something much more powerful.
>
>
>
>
>> * Attribute Driven (Dependency Level)
>>
>> Similar to above, but the attribute is associated with
>> the dependency. The lookup operation would consider the
>> supplied string as a locally scoped key, and the policy
>> would determine if the container handler selection of the
>> implementation delegated selection to the client.
>>
>> - advantages, mixes both scopes within a single component
>> - disadvantages, requires all ECM style components to
>> declare a formal meta-info model (which is a good thing, but is
>> practical/achievable)
>>
>>
>
>We have been pushing for not needing the ECM or the ...Selector.
>Therefore, this is a much better solution. The thing is when we
>have it working in both Merlin and Fortress, we make a release and
>deprecate the ECM.
>
>
>
>
>> * A new Lifecycle Interface
>>
>> If we were to assume that the lookup operation was
>> restricted to locally scoped names (role name to service
>> provider mapping), we could image a separate interfaces
>> through which non-local service requests are resolved.
>> Such an interface could be something like:
>>
>> public interface Locator
>> {
>> public Object locate( String role );
>> }
>>
>> - advantages, clear separation of concerns with respect
>> to the different semantic models, relatively strait-
>> forward migration strategy for ECM style components,
>> easy to implementation within containers
>>
>> - disadvantages, a new lifecycle interface (which is not
>> something to be consider lightly)
>>
>> - notes, could be handled as an lifestyle extension
>>
>>My own preference would be to kick-off some trials using a
>>Locator interface implemented as a Creator extension class.
>>
>>
>
>
>What difference is there between this and the ...Locator
>class we proposed for A5?
>
The difference is that I'm isolating semantics and saying that:
a) a ServiceManager.lookup( ... ) handles the role argument as
a key within the scope of the component - i.e. doing a lookup
with an interface class name or a "Selector" would be meaningless
(and would generate a ServiceException becuase it is unknown in
the components role to service map)
b) a ServiceLocator.locate( ... ) handles resolution of services
based on a supplied interface class name and handles "Selector"
semantics. It does not know anything about the notion of scoped
keys - its pure ECM/Fortress style lookup management.
Two different semantics, two different interfaces.
>The ...Locator is essentially a replacement for SeviceManager,
>at least as far as I can tell. I don't really see any compelling
>reason to make that move *now*.
>
I'm not thinking about anything to do with A5 (in fact the further away
A5 drifts the better as far as I am concered). What I'm focssing on is
the seperation of quite different semantics that are currently in use
across one interface (which is BAD, BAD, BAD). This difference in
interpritation in a weakness in the framework that can be addressed by
seperating the concerns - and should be addressed as part of A4. I'm
basically looking for a way to provide a clean and consitent approach to
ECM/Fortress/Cocoon service location within the scope of a formal
structured meta driven framework.
Cheers, Steve.
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: lookup semantics
Posted by Berin Loritsch <bl...@apache.org>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> As part of the work on Fortress/Merlin and an in the context
> of Cocoon requirements, I'm starting to think about the best
> way to handle the different semantic models related to the
> lookup operation on CM/SMs.
>
> Current Status
> --------------
>
> * ECM/Fortress style
>
> The CM/SM implementation treats the supplied string as
> the classname of a component interface. It also allows
> certain suffix values such as ...Selector. The selector
> suffix is interpreted during the lookup resolution resulting
> in a selector implementation reference returned to the client.
>
> * Merlin/Phoenix style
>
> The string argument supplied to the CM/SM is resolved against
> a table of role names, mapped to component implementations.
> No support is provided for the Selector suffix.
At the current moment, this will have to do. We want to allow
users to get rid of their dependency on ...Selector. The Fortress
approach allows that to happen, but we want to discourage the
use of the ...Selector as much as possible.
> Possible Approaches
> -------------------
>
> There are several possible approaches to resolving this issue:
>
> * Attribute Driven (Type Level)
>
> Imagine that a type declared something like a
> avalon:lookup-scope policy in its meta-info attribute set.
> This policy value could be set to indicate if scope of
> lookup is VM wide or constrained to the component type
> (ECM versus Merlin semantics).
>
> - advantages, relatively easy to implement
> - disadvantages, scope is at the level of a component
> so the mixing of both style in a single component
> is compromised
-1 The Fortress approach is good enough, and this doesn't provide
anything really different. We want to replace the ...Selector
with something much more powerful.
> * Attribute Driven (Dependency Level)
>
> Similar to above, but the attribute is associated with
> the dependency. The lookup operation would consider the
> supplied string as a locally scoped key, and the policy
> would determine if the container handler selection of the
> implementation delegated selection to the client.
>
> - advantages, mixes both scopes within a single component
> - disadvantages, requires all ECM style components to
> declare a formal meta-info model (which is a good thing, but is
> practical/achievable)
We have been pushing for not needing the ECM or the ...Selector.
Therefore, this is a much better solution. The thing is when we
have it working in both Merlin and Fortress, we make a release and
deprecate the ECM.
> * A new Lifecycle Interface
>
> If we were to assume that the lookup operation was
> restricted to locally scoped names (role name to service
> provider mapping), we could image a separate interfaces
> through which non-local service requests are resolved.
> Such an interface could be something like:
>
> public interface Locator
> {
> public Object locate( String role );
> }
>
> - advantages, clear separation of concerns with respect
> to the different semantic models, relatively strait-
> forward migration strategy for ECM style components,
> easy to implementation within containers
>
> - disadvantages, a new lifecycle interface (which is not
> something to be consider lightly)
>
> - notes, could be handled as an lifestyle extension
>
> My own preference would be to kick-off some trials using a
> Locator interface implemented as a Creator extension class.
What difference is there between this and the ...Locator
class we proposed for A5?
The ...Locator is essentially a replacement for SeviceManager,
at least as far as I can tell. I don't really see any compelling
reason to make that move *now*.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>