Berin Loritsch wrote:
>>From: Stephen McConnell [mailto:[EMAIL PROTECTED]]
>>
>>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.
>>>>>
>>>Developing with Avalon?
>>>
>>>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.
>>
>>Cheers, Steve.
>>
>
>Steve, with all do respect, I do not know what your "-1" is supposed
>to signify.
>
The document in question talkes about an approach - using terms such as
"you can", "you may", "the preferred approach", etc. The document in
question is introducing Avalon by example and takes the reader through
the rationale and justification for the existance of ECM. My -1 is a
vocal objection to the assertion that the principals and best practices
sited in that particular document constitute binding defintions.
>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.
>
Sorry - I disagree. The javadoc is part of what we have voted on. We
put in place ServiceManager as the replacement of ComponentManager and
we voted on that - we voted on the implementation sources and the
javadoc. Those sources were for all intensive purposes totally
equivalent to ComponentManager - and neither describe any such
historical conclusion. Lets get real - when we produce framework
content the javadoc is part of the defintion.
>
>With this restriction, I looked at ways of programatically enforcing the
>Role to be the interface class, or something more concrete.
>Unfortunately, the interface class won't work because of classloader
>issues (if a class is loaded in separate classloaders, it is considered
>to be a different class). And I have not been able to come up with an
>agreeable object that 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.
>
This is only true in the ExcaliburComponentManager scenario.
It is not true of the general case. The general case is much simpler -
a component request a service from its manager by using the role
argument. It is a implementation issue as to how a CM/SM is populated
in order to satisfy the component requests. The moment you are
introducing any semantics into the role value - you imply a contract
between the container the the component. If you were to take that
component as stick it into Phoenix and Merlin it would be supplied with
a DefaultComponentManager or DefaultServiceManger implementation and as
you know, both implmementations are strictly consistent with the
resopective interface definitions - i.e. the role is a string that is
used by the component to reference a dependent service/component.
Neither DCM or DSM do anything related to classloading - they are
supplied with prepared services/components.
>
>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? The reality is that they are separate
>roles.
>
Hang on ----- I create a component - it has needs three service, its
refers to those services using roles "fred", "george" and "mary". The
role names are simply the keys used by the component to locate the
services - they are not defintions of what the service is (at least at
the level of the Avalon framework). These keys are also unique within
the scope of the component - a.k.a. it's a component conecern. A
particular container may choose to provide a dynamic CM/SM - one that
recoginises certain semantics with respect to role names that are
supplied to a CS/SM - but that's simply an implementation approach that
is restricted to a family of components that are portable within that
context. What you cannot do is to infer those implemetation semantics
onto framework interfaces. The approach taken to the establishment of a
functional CM/SM is orthogonal to the specific question of key used by
the component to lookup the service.
Cheers, Steve.
--
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]>
