Pete:
Your summary is mixing two separate concerns:
1. the concern related to key management
The key management issue is address by apply the convention
of public static final String KEY = "some-opaque-value". This
ensures that components can apply a consistent usage pattern
when referencing key values in code. This is orthogonal
to the question of the actual string value.
The usage is KEY is a valid best practice that can be
validated and/or enforced and is consistent with the framework
usage.
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.
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
(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.
Cheers, Steve.
p.s. sins concerning metainfo back-pointers are forgiven
- a solution has emerged :-)
Peter Donald wrote:
>Roles as interface Pattern
>--------------------------
>We have pretty much always used this since day 1 (or at least since I been
>here). The main reason is that it allows a cleaner separation between
>interface and implementation and easier classloader management if we need to
>separate the two concepts. Phoenix enforces this and I believe ECM may
>aswell?
>
>Role Names as ClassName + "/somekey"
>------------------------------------
>This was established after we ran into trouble maintaining keys. ie We had
>changed the rolename in container but forgot to update the components or vice
>versa. After this happened a few times we decided to standardize on name of
>class. However a couple of times we broke cocoon because we moved components
>without updating their role strings. So now we recomend that you have the
>Role name auotmatically maintained via
>
>String ROLE = MyClass.class.getName();
>
>That way you always know what it will be and it will only change when you move
>class (which requires a recompile of all the classes anyways).
>
>The practice of psostfixing it with "/someKey" was arbitarily chosen. The "/"
>was chosen as then you could validate the best practice of using
>rolename=classname however the key part is an arbitary string.
>
>It is true that no container actually enforces this but Phoenix does make it
>easier if you follow this pattern. ie You don't have to declare <role/> if it
>matches service name. In the future it may also issue warning if role names
>don't match pattern. (Had a request for that but forgot to implement it).
>
>
--
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]>
