RE: [picocontainer-dev] Ambiguity resolution?
Jörg Schaible <[email protected]>
| Newsgroups | gmane.comp.java.picocontainer.devel |
|---|---|
| Message-ID | <[email protected]> |
Konstantin Priblouda wrote: > > --- Jörg Schaible > <[email protected]> > >> > Yes, but in this case child integer is not masking >> > parent - it got different key. So IMHO this shall >> > produce ambiguity. >> >> No. The parent is only requested if the child >> container cannot resolve the dep (note, this is >> different for a collection). In this case the child >> is requested for an arbitrary Integer instance ... >> and it can provide one. So no ambiguity. The key is >> only considered if the type of two components *in >> the same* container match. > > so you mean that ambiguous resolution is given only > if there are ambiguous components on certain level? Definitely. > the question is, whther this is correct behavour - > I would prefer that same kind of resolution by type > for whatever puprose. The parent container is only a fallback. > another issue is with testMoreWeirdness - adapter > keyed with desired class wins over others while > resolving by class - only on same level, or in > parent too? In parent too: public static class MyX implements InterfaceX { public String getIt() { return "myX"; } } public void testMoreWeirdnessWithParent() { MutablePicoContainer parent = new DefaultPicoContainer(); MutablePicoContainer pico = new DefaultPicoContainer(parent); Map map = new HashMap(); parent.addComponent(map); // See class level javadoc in DefaultPicoContainer - about precedence. parent.addComponent(InterfaceX.class, MyX.class); pico.addComponent(Disabled.class); pico.addComponent(Enabled.class); pico.addComponent(NeedsInterfaceX.class); NeedsInterfaceX needsInterfaceX = pico.getComponent(NeedsInterfaceX.class); assertEquals("myX", needsInterfaceX.getIt()); } The first search addresses a key of same type. If the current container does not have one, the parent is used as fallback. If it does not have one too, the search continues in current container for components with compatible types. - Jörg --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email