At 03:50 AM 6/12/2002 +0200, you 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 myrmidon and fortress and Phoenix/Merlin also encourage it by not requiring bulkage in config files if not the case. > This may be a valid best practice within the scope of ECM > but it is inconsistent with the specifications at the framework > level. > >Attempt at enforcing the "principal" that a key corresponds to an >interface effectively negates the potential for multiple service provision >where a interface is shared by more than one provided service No it does not. Decorate it at end with a "/key" and voila multiple service provision of service with same interface. >(without resorting to implementation workarounds such as a component >selector). This is simply because keys are dealing with "instances" of >services that a component implementation requires. Interface names are >"type" level. While interface names may be convenient in the majority of >cases - it is not definitive and any attempt to enforce the rule will not >only introduce unnecessarily constraints on a developer - but will also >break existing components with more subtile role/service relationship. Im not sure exactly what the problem is. It is enforced in several containers, is implemented in all the avalon hosted components (except yours) and by following pattern you can reuse component between multiple containers. When I asked you why you not follow pattern you told me it was for pragmatic reasons - ie role name == name of logger used for dependency. However this could easily be stored as an attribute of dependency so I am not sure that still holds? -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
