Leo Simons wrote:
>>>Berin Loritsch wrote:
>>>
>>>
>>>
>>>>>From: Stephen McConnell [mailto:[EMAIL PROTECTED]]
>>>>>
>>>>>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:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
