Details
-
Type:
Bug
-
Status:
Resolved
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 2.4
-
Fix Version/s: 2.5
-
Component/s: PicoContainer (Java)
-
Labels:None
-
Testcase included:yes
-
Number of attachments :
Description
Test cases:
Plunk them into AbstractPicoContainerTest for demo:
/**
* Sample class that demonstrates literal collection handling.
*/
static class Searcher {
private final List<String> searchPath;
public Searcher(List<String> searchPath) {
this.searchPath = searchPath;
}
public List<String> getSearchPath() {
return searchPath;
}
}
@Test public void canInstantiateAutowiredCollectionThatAreDefinedExplicitly() {
MutablePicoContainer pico = this.createPicoContainer(null);
List<String> searchPath = new ArrayList<String>();
searchPath.add("a");
searchPath.add("b");
pico.addComponent("searchPath",searchPath)
.addComponent(Searcher.class);
assertNotNull(pico.getComponent(Searcher.class));
assertNotNull(pico.getComponent(Searcher.class).getSearchPath());
}
@Test public void canInstantiateExplicitCollectionWithComponentParameter() {
MutablePicoContainer pico = this.createPicoContainer(null);
List<String> searchPath = new ArrayList<String>();
searchPath.add("a");
searchPath.add("b");
pico.addComponent("searchPath",searchPath)
.addComponent(Searcher.class, Searcher.class, new ComponentParameter("searchPath"));
assertNotNull(pico.getComponent(Searcher.class));
assertNotNull(pico.getComponent(Searcher.class).getSearchPath());
}
Issue Links
- is related to
-
PICO-323
Handle differentiation of components by Type rather than Class.
-
Activity
Then again, I'm sure we could get it going with current API signatures by 'concreting over generics' :
class MySomethingList extends ArrayList<String>
{ // etc }mpc.addComponent(MySomethingList.class);
Paul Hammant
added a comment - Then again, I'm sure we could get it going with current API signatures by 'concreting over generics' :
class MySomethingList extends ArrayList<String>
{
// etc
}
mpc.addComponent(MySomethingList.class); The old collection functionality did only collect if no matching type was already available as component i.e. you could register a String[] and five different Strings ... a component with a dependency to a String[] would have received the registered array, but not the 5 Strings. Only if no array was available, the five strings were provided as array to the component.
Jörg Schaible
added a comment - The old collection functionality did only collect if no matching type was already available as component i.e. you could register a String[] and five different Strings ... a component with a dependency to a String[] would have received the registered array, but not the 5 Strings. Only if no array was available, the five strings were provided as array to the component. True, but I think the thing that bugs me about it is that I want
pico.addComponent(MyObject.class, MyObject.class, new ComponentParameter("test"));
to give me the component 'test' in the constructor, and somehow deep in the bowels of the object construction, my request is getting overridden.
(Or speaking in terms of the test case, I really need canInstantiateExplicitCollectionWithComponentParameter() to work, but I don't care if canInstantiateAutowiredCollectionThatAreDefinedExplicitly() works)
Michael Rimov
added a comment - True, but I think the thing that bugs me about it is that I want
pico.addComponent(MyObject.class, MyObject.class, new ComponentParameter("test"));
to give me the component 'test' in the constructor, and somehow deep in the bowels of the object construction, my request is getting overridden.
(Or speaking in terms of the test case, I really need canInstantiateExplicitCollectionWithComponentParameter() to work, but I don't care if canInstantiateAutowiredCollectionThatAreDefinedExplicitly() works)
One additional thing: The described behaviour only applied for a ComponentParameter. You could have registered the component depending on a String array explicitly with a CollectionComponentParameter ... in that case the matching String array was ignored and the component got the collection of the 5 strings as well 
Jörg Schaible
added a comment - One additional thing: The described behaviour only applied for a ComponentParameter. You could have registered the component depending on a String array explicitly with a CollectionComponentParameter ... in that case the matching String array was ignored and the component got the collection of the 5 strings as well The way I outline (full generic declaration) will require changes to PicoContainer methods .. Class to Type specifically.
I've worked it through.
Paul Hammant
added a comment - The way I outline (full generic declaration) will require changes to PicoContainer methods .. Class to Type specifically.
I've worked it through. So lets move the full generic declaration to Pico 3. I've got what I need so I'm not in a rush for anything else. I'll resolve this, and add a wish for Pico 3 for housekeeping.
Michael Rimov
added a comment - So lets move the full generic declaration to Pico 3. I've got what I need so I'm not in a rush for anything else. I'll resolve this, and add a wish for Pico 3 for housekeeping. Fixed the functionality that I was looking for. I'm proposing that we move full Generic handling to Pico 3.
Michael Rimov
added a comment - Fixed the functionality that I was looking for. I'm proposing that we move full Generic handling to Pico 3. Agree,
Paul Hammant
added a comment - Agree, 
Yeah, we never got that far in terms of functionality.
If you add a and b to the container as strings individually, it will work.
I think to get what you want working perfectly we'd have to change addComponent(Class, Class) to addComponent(Type, Type)