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). -- Cheers, Peter Donald ---------------------------------------- Why does everyone always overgeneralize? ---------------------------------------- -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
