Niclas Hedhman <niclas <at> hedhman.org> writes: > > What's the problem of a generic interface? Isn't it an issue of the > > implementation to be more specific? > > 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? > > And how should it be done instead? > > Since the "selection process" is tied to the component (i.e. it knows how it > wants to provide "hints"), Yes, Avalon concepts are mostly as abstract as possible and at the end nobody gets the idea what they could mean :) > the Avalon community back then came to the > conclusion that the generic selector pattern is no good, and should be done > by component specific selectors. > > Now, since there are N ways of implementing this, it is little bit up to you > to take a step back and say; "What do I really need?" and not looking at what > is provided in "the old days". 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? ... code samples snipped ... > But there might be endless variations on what can happen, hence the decision > to deprecate and discourage the use of service selectors. Ok, the specific selection is not that difficult I guess. But I found out that even the selector does not solve the issue I mostly fear: the life cycle handling of a component. I had a look into different selector implementations and found that they do the lifecycle handling themselves (calling enableLogging(), service(), initialize() and so on as e.g. in http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/web3/java/org/apache/ cocoon/components/web3/impl/Web3DataSourceSelectorImpl.java?annotate=1.6#150). 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. If this mail contains to much twaddle you can derive I'm a newbie on this area :) Joerg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
