avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: lookup semantics
Date Fri, 23 Aug 2002 14:13:33 GMT


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:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:avalon-dev-help@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:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message