PicoContainer

Cannot instantiate objects that have an specific collection in their constructor.

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Major 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 :
    0

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

Activity

Hide
Paul Hammant added a comment -

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)

Show
Paul Hammant added a comment - 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)
Hide
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);

Show
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);
Hide
Joerg 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.

Show
Joerg 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.
Hide
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)

Show
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)
Hide
Joerg 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

Show
Joerg 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
Hide
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.

Show
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.
Hide
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.

Show
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.
Hide
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.

Show
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.
Hide
Paul Hammant added a comment -

Agree,

Show
Paul Hammant added a comment - Agree,

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: