Niclas Hedhman <niclas <at> hedhman.org> writes:
No, the issue at hand is that IF the client-component is written against a "observed behaviour" of a particular container, re-use and interchangeable compents between containers suffers.
Sorry, but I don't get it. Why is the selector container specific?
because some containers (ie Phoenix) do not support the mechanism. I'm not sure whether merlin supports it, and if its mechanism is fully compatible with the one used in fortress and ecm (which are compatible).
Ok. So the selection itself is ok, but not the to generic service selector. but then the statement "the usage service selector might be related to bad design" is to universal, isn't it?
yes :D
I like the idea of getting completely initialized components back without any care about the lifecycle (like for manager.lookup()), but maybe the selector is to deep inside the container to expect this here too.
in the ecm/cocoon case, yep :D
If you develop your own semantics, you have many different options (use a container inside the selector, use one alongside, use the main container inside the selector, use some heuristics...). None of them is always superior. Pick one, try it, if it works, stick with it :D
-- cheers,
- Leo Simons
----------------------------------------------------------------------- Weblog -- http://leosimons.com/ IoC Component Glue -- http://jicarilla.org/ Articles & Opinions -- http://articles.leosimons.com/ ----------------------------------------------------------------------- "We started off trying to set up a small anarchist community, but people wouldn't obey the rules." -- Alan Bennett
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
