avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@osm.net>
Subject Re: [proposal] avalon 5 ComponentManager interface
Date Tue, 11 Jun 2002 15:08:46 GMT


Leo Simons wrote:

>>>Berin Loritsch wrote:
>>>
>>>      
>>>
>>>>>From: Stephen McConnell [mailto:mcconnell@osm.net]
>>>>>
>>>>>Leo Sutic wrote:
>>>>>
>>>>>          
>>>>>
>>>>>>The need for hints exist because we have decided that the 
>>>>>>            
>>>>>>
>>>role should 
>>>      
>>>
>>>>>>be an interface name.
>>>>>>
>>>>>>            
>>>>>>
>>>>>Slowdown here - can anyone/someone please refer me to any Avalon
>>>>>framework documentation anywhere that states a role is an interface 
>>>>>name?  Please - let's not get mixed up between decisions 
>>>>>concerning ECM. 
>>>>>The CM/SM is not and does not inherit from ECM.
>>>>>          
>>>>>
>>>>It's a decision we came to a long time ago.
>>>>
>>>>        
>>>>
>>>-1
>>>
>>>The "decision" is not documented in the CM/SM interfaces - is not 
>>>enforced by anything in the framework least of all 
>>>DefaultComponentManager or DefaultServiceManager.  But the 
>>>worst thing 
>>>of all is that implies the potential interpritation of the 
>>>lookup key on 
>>>a CM/SM manager implemetation. The decision I accept is the decision 
>>>expressed by the CM/SM interfaces and the javadoc that goes with them.
>>>      
>>>
>>Steve, with all do respect, I do not know what your "-1" is supposed
>>to signify.  The fact that it isn't properly represented in the javadocs
>>documentation doesn't negate the fact that historically the team came
>>to that conclusion.  It does not negate the fact that it was the
>>tradition imposed by Federico, who convinced both Peter and I (no small 
>>feat I might add) that it was the best way.
>>    
>>
>
>It is a tradition, a recommendation, and a "best practice". It is _not_
>a requirment.
>

I have to question this "best practice".  It is completely possible for 
a component to maintain its own role namespace which is a fundamental 
characteristic if your doing any sort of complex system.  Furthermore 
nobody has provided a rationale for this beyond "a tradition imposed by 
Federico" which just does not stack-up.  A best practice is normally 
founded on rationle that is defensible.  The only rationale that can be 
infurred is the association to ECM patterns of usage and I don't think 
ECM represents best-practice.

>>enforces the role abstraction.  The important thing is that the Role is
>>tightly coupled to its interface--and as such the lookup name should be
>>the Role's interface name.
>>    
>>
>
>The important thing is that the Role is tightly coupled to its
>interface--and as such the lookup name should be tightly coupled to the
>Role's interface name.
>
>important difference.
>
>We could tighten this to the lookup name should start with the results
>of getClass().toString() called on the role interface, minus the
>starting "interface ".
>  
>

This would introduce an artifical and unnecessary limitation?
Here is an implementation approach that does not mix the lookup key with 
the service/component that is returned.

      <dependency>
          <role>something-basic</role>
          <service name="org.apache.excalibur.assembly.demo.BasicService"/>
      </dependency>

There is no ambiguity here - the service dependecy is clearly started 
and completely consistent with a component centric management of a role 
namespace.

>  
>
>>The decision stems from the best way to have a unique name for a role,
>>without being subject to naming clashes.  It would be really bad and
>>incorrect if I received a component implementing
>>"com.infoplanning.Store"
>>when I really wanted something implementing
>>"org.apache.excalibur.Store".
>>If the role name in the CM was simply "Store", which one should the
>>container
>>return?  Under which circumstances should it return the
>>"com.infoplanning"
>>version and which circumstances should it return the
>>"org.apache.excalibur"
>>version?
>>    
>>
>
>this is determined by the combination of container programmer (design
>time) and assembler (initialization time) (just to answer the question
>for those that might not know the answer).
>

Agreed.

>
>
>In the case of phoenix, it depends on the xml configuration files fed
>into it by the assembler.
>

Which is an approach that can be used outside of Phonix in the runtime 
creation of service by a container when servicing/composing its 
services/components.

>>Would you rather set up an authority to come up with id's like ICANN?
>>    
>>
>
>ugh. The thing both sun and w3 figured out is that basing yourself on
>ICANN id's is the only way to fly =)
>
>You forget the other alternative allowed (regardless of whether this is
>by code or contract) is for framework users to be their own authority.
>

The scalable approach is for the component to manage its own role 
namespace (through a clean seperation of lookup role and the 
computational dependecy).

>final note: coupling role name to interface only gives as much namespace
>clash avoidance as the java namespace mechanism, which still depends on
>trust (unless you use signed jars). I'd suggest not trying making it
>more solid.
>
>- Leo, who always follows "best practice" in his own projects
>  
>

Steve - who tends question and understand why something is a best 
practice before following.

:-)


-- 

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