> 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 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. 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. 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. Would you rather set up an authority to come up with id's like ICANN? The "-1" doesn't change a decision already made--with good reason. All it might do is inspire us to document it in the Javadocs. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
