Details
-
Type:
New Feature
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 1.2-RC2
-
Fix Version/s: 1.3
-
Component/s: PicoContainer (Java)
-
Labels:None
-
Number of attachments :
Description
I have a class with two constructors, a no-args one and one with two arguments.
I pass is one of the arguments as a constant Parameter. The other argument is not satisfiable at this point. I expected Pico to use my default constructor but instead it tried to use the other one and throw an exception.
I can see the problem is in this bit of code:
// filter out all constructors that will definately not match
for (int i = 0; i < allConstructors.length; i++) {
Constructor constructor = allConstructors[i];
if ((parameters == null || constructor.getParameterTypes().length == parameters.length) && (allowNonPublicClasses || (constructor.getModifiers() & Modifier.PUBLIC) != 0))
}
Because I pass in one parameter the 0 args constructor is not even considered.
Activity
Jörg Schaible
made changes -
| Field | Original Value | New Value |
|---|---|---|
| Type | Bug [ 1 ] | New Feature [ 2 ] |
| Fix Version/s | 1.3 [ 11331 ] | |
| Assignee | Joerg Schaible [ joehni ] |
What about the case where I want to specify some of the parameters and let Pico fill in the blanks? Can it not simply use the provided parameters when deciding what constructors are satisfiable?
John Patterson
added a comment - What about the case where I want to specify some of the parameters and let Pico fill in the blanks? Can it not simply use the provided parameters when deciding what constructors are satisfiable? Also planned, it is just a "filling up" with default parameters. Biggest culprit is precedence in case of multiple ctors. It should stay predictable.
Jörg Schaible
added a comment - Also planned, it is just a "filling up" with default parameters. Biggest culprit is precedence in case of multiple ctors. It should stay predictable. Actually, I believe that this bug is invalid (unless it was already fixed and this hadn't been closed).
If you wish to call the no arg constructor then you should an empty Parameter array like so:
pico.registerComponentImplementation(NoArg.class, NoArg.class,
new Parameter[] {} )
In the case of new Parameter[]
{new ComponentAdapter()}, it should mean to pico to autowire the first argument in a constructor, so it would ignore a no-arg constructor.
I've added the test case:
org.picocontainer.tck.AbstractPicoContainerTestCase.testNoArgConstructorToBeSelected()
to prove that it works. (I decided that it was an important enough edge case to add to the TCK).
Javadocs have been updated in MutablePicoContainer to talk about this.
Michael Rimov
added a comment - Actually, I believe that this bug is invalid (unless it was already fixed and this hadn't been closed).
If you wish to call the no arg constructor then you should an empty Parameter array like so:
pico.registerComponentImplementation(NoArg.class, NoArg.class,
new Parameter[] {} )
In the case of new Parameter[]
{new ComponentAdapter()}
, it should mean to pico to autowire the first argument in a constructor, so it would ignore a no-arg constructor.
I've added the test case:
org.picocontainer.tck.AbstractPicoContainerTestCase.testNoArgConstructorToBeSelected()
to prove that it works. (I decided that it was an important enough edge case to add to the TCK).
Javadocs have been updated in MutablePicoContainer to talk about this. Michael Rimov
made changes -
| Assignee | Joerg Schaible [ joehni ] | Michael Rimov [ rimovm ] |
| Resolution | Fixed [ 1 ] | |
| Status | Open [ 1 ] | Closed [ 6 ] |
This is by design. If you specify the number of parameters, you specify the arity of the ctor. Nevertheless with the changes planned in
PICO-160I also have in mind, that the given parameters should be used to satisfy any ctor that has up-to the number of provided parameters and independent of their sequence.