Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bean definitions using indexed constructor arguments are not usable for @Autowired resolution [SPR-11019] #15647

spring-issuemaster opened this issue Oct 22, 2013 · 1 comment


Copy link

@spring-issuemaster spring-issuemaster commented Oct 22, 2013

Ryan Gardner opened SPR-11019 and commented

I created some bean definitions in my BeanRegistry and was using indexed constructor arguments.

When using @Resource, the beans were resolved properly by type.

When using @Autowired, they were not found.

We traced it down to:

line 635 of the AbstractAutowireCapableBeanFactory in the getTypeForFactoryMethod method

List<ValueHolder> argumentValues = mbd.getConstructorArgumentValues().getGenericArgumentValues();

This code only looks for methods based on argument values set as GenericArgumentValues - any set via indexedArgumentValues are not found.

switching our code to create bean definitions using GenericArgumentValues instead of IndexedArgumentValues fixed the issue for us, but this seems like an oversight.

Changing it slightly to something like this should at least address this one case:

List<ValueHolder> argumentValues = mbd.getConstructorArgumentValues().getGenericArgumentValues();
if (argumentValues.size() == 0) {
     argumentValues = mbd.getConstructorArgumentValues().getIndexedArgumentValues();

(feel free to use the above code - I've signed the spring contributor agreement... if you want I can do this on a branch and submit a pull request for it)

Affects: 3.2.4

Referenced from: commits 42568af, 109faac


This comment has been minimized.

Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Oct 26, 2013

Juergen Hoeller commented

I've addressed this through following the same argument lookup algorithm that ConstructorResolver itself uses when invoking a constructor or factory method. Any mix of generic and indexed arguments and even named arguments should work now.


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
2 participants
You can’t perform that action at this time.