This is probably intentional behavior, or at least "not accommodated", but just in case...

I ran into a case where using a child and parent in combination broke because I hadn't noted that my parent bean specified the first argument by ordinal, and then I inadvertently specified all three constructor arguments by name in the child bean. This caused the instantiation to fail with a generic "can't find matching constructor" exception message.

For example:

<bean id="theParent" class="....something" c:_0="arg" />

<bean id="theChild" parent="theParent" c:arg1="arg" c:arg2="arg" c:arg3="arg" />

I would guess it's too much hassle and probably somewhat of a combinatorial explosion to expect this to work, but I guess it might be nice to have a more specific error message if the problem occurs and it notices there are arguments on both perhaps.

Close if this is intentional obviously.

Comment From: sbrannen

I would guess it's too much hassle and probably somewhat of a combinatorial explosion to expect this to work, but I guess it might be nice to have a more specific error message if the problem occurs and it notices there are arguments on both perhaps.

Indeed, that combination is not expected to work, and we have no plans to make it work.

Though, you're right: a better error message would improve diagnostics when such failures occur.

So we will investigate if we can improve the error message in 6.0.x.

Comment From: simonbasle

AFAIK it is not possible to distinguish the source of the constructor arguments, as they're flattened down into a single ConstructorArguments when creating the ChildBeanDefinition. It is also not trivial to detect the mismatch, but the message could be changed anyway by adding a second "hint". Here is what I have in mind for the end of the BeanCreationException message:

(hint: specify index/type/name arguments for simple parameters to avoid type ambiguities.
You should also check the consistency of arguments when mixing indexed and named arguments, 
especially in case of bean definition inheritance)

will open a PR accordingly. the phrasing can be discussed there if needed.

Comment From: simonbasle

Continued in PR #30169