avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@osm.net>
Subject Re: [A5] CM Use Cases from real requirements
Date Wed, 19 Jun 2002 08:45:26 GMT


Leo Sutic wrote:

>  
>
>>From: Stephen McConnell [mailto:mcconnell@osm.net] 
>>
>>Leo Sutic wrote:
>>
>>    
>>
>>>Stephen,
>>>
>>>1) What will the CM interface look like? I think you just end 
>>>   up back where you started...
>>> 
>>>
>>>      
>>>
>>I've been using the CM term relative to Avalon 4 
>>ComponentManager, or, Avalon 4 ServiceLocator or 
>>ServiceManager as a A4 migration path.
>>    
>>
>
>I'm talking about the CM interface in your drawing. The little
>box labeled "CM".
>  
>
Thats the component manager supplied by the container to the component.

>  
>
>>>2) what is the difference between ComponentRegistry and a 
>>>   ComponentSelector?
>>>
>>>      
>>>
>>The important difference is the the ComponentRegistry is not 
>>part of the 
>>Avalon Framework, its just a service interface, possibly 
>>something that 
>>could live in Excalibur land.  The actual operations exposed by that 
>>interface could then be crafted to match the ECM/Cocoon/Fortress 
>>application space - e.g. it would extend from Component (to 
>>be backward 
>>compatible with CM), and it would contain a suite of lookup 
>>operations 
>>that leverage structured roles, hints, queries, whatever the 
>>ECM/Fortress/Cocoon community think is rational (i.e. 
>>minimise migration 
>>headaches).
>>
>>Sound good?
>>    
>>
>
>Not really... I think you are pushing too much to the client.
>It would appear that for most normal use cases, the client needs
>to supply a ComponentRegistry.
>  
>

Think of ComponentRegistry as the thing the handles service requests 
(i.e. lookup strings are interprited).

>What we end up with is a framework that isn't constrained *enough* -
>there's no point in using it, as you end up having to code very
>much yourself anyway.
>  
>

Bring in the notion of an intemidiate ComponentRegistry provides a 
solution that parrallels ECM/Fortress approaches but enables coponent 
that fully publish their contracts (via meta) to use a component manager 
with pure container/component semantics. Its a strategy that will enable 
painless migration.

>Overall this is a problem with the A5 effort - in an effort to
>get cleaner architecture, we have very much removed the ease of
>use of A4. In A5 you need to write your own XXXXManagers, your own
>ComponentRegistry, etc., etc... Basically, you are saying that
>

I have the impression your missunderstanding the function of a component 
registry.  This is simply something very similar to that part of ECM and 
Fortress that handles lookup with a string value that is interprited by 
the container (as opposued to the use of a lookup string which is an 
opaque key).  The registry is built by the container and provided by the 
container, specifically to serve those components that have embedded 
deopedency information inside lookup argument values (instead of 
declaring this as part of meta).

>
>    for the single most common use case of the framework, 
>    the framework will not provide any formalized interfaces,
>    at all!
>
>Everything is pushed onto the client in some bizzare interpretation 
>of SoC. This is not SoC, it's a gaping hole in Avalon's feature set.
>If that separates anything it separates potential users from the 
>framework.
>  
>

Not following the last bit.  
Let's clean up the understanding of the approach I'm decribing - then 
when that's clear - we can talk about gaping holes and feature sets.

Cheers, Steve.

>/LS
>
>
>--
>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