avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@apache.org>
Subject RE: lookup semantics
Date Fri, 23 Aug 2002 14:07:02 GMT
> 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:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message