Peter Donald wrote:
>On Wed, 12 Jun 2002 11:50, Stephen McConnell wrote:
>
>> 2. the concern related to ECM
>>
>> ECM uses the role name together with some implementation
>> magic to support resolution of services exposed under the
>> component manager interface. In this context, the association
>> of an interface name as a key value is consistent with the
>> design of ECM.
>>
>
>And phoenix. ie It is less work to comply with this than it is not to comply
>and all of cornerstone and friends comply with it. If you comply then you
>need not define <role> elements and your .xinfo files are cut by a third.
>
No problem with the notion that in the context of no role declaration at
the level of meta information then the role name is asumed to be the
class name of the request services. That's not in conflict. Its a
"convention"that can be applied by a container in the absence of other
information - not a "best practice". The application of the convention
can be a recommendation - but the overriding rule is that a component is
control of its own role naming scope.
>
>I am not saying it should always be enforced but it can be recomended.
>
I agree that this can recommended as a naming convention on that grounds
of things like default values.
>ie I
>have been asked in the past to put in a check. For every role string do
>something like
>
>int index = role.indexOf( '/' );
>if( -1 != index )
>{
> role = role.substring( 0, index );
>}
>
>if( role != interfaceName )
>{
> issueWarning();
>}
>
>I consider it valid best practice in any container. It need not be enforced
>but it is good to do.
>
I really object to the "issue a warning" - simply because this is not
the kernel concern. A component using "Fred", "George" and "Mary" as
role names is valid and consistent. In conclusion - the application of a
the convention of interface names is valid for defaults. Secondly, I
agree with the convention that role names should be assigned under
public static KEY value as means to address key management. I do not
agree that the value returned from KEY should be considered as anything
but opaque as far as a container or kernel is concerned. See prev.
email for snipped rationale.
:-)
--
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]>
