Inconsistent behavior when autowiring multiple beans by type as collection without matching beans

[therob]

Affects: 5.1.0 and later

Autowiring multiple beans as a collection results in different behavior depending on the type of injection used when no matching beans are found.

Using field injection or setter injection leads to an UnsatisfiedDependencyException. Whereas constructor injection results in an empty collection. According to the docs this should fail too.

1.9.2. Using @Autowired

By default, the autowiring fails whenever zero candidate beans are available. The default behavior is to treat annotated methods, constructors, and fields as indicating required dependencies.

A demo of this can be found here: https://github.com/therob/bug-demo-inject-collection
Just execute the included test with mvn test or your favourite IDE.

[jhoeller]

This is by design: see #19901, applying to unique constructors where no resolution of overloaded constructors is necessary. Constructors are generally different from fields and methods there in that we cannot simply skip them if they are not required, we can only fall back to a less greedy constructor or fail. And for modern design purposes, a single unique constructor or factory method with a collection argument is common enough to warrant specific support. Before, it was rather surprising that a collection (typically among several arguments) cannot be empty in a scenario where there is no fallback.

Point taken though that this is not properly reflected in the documentation. I'll turn this into a doc ticket.

[therob]

Thanks for the quick reply. I didn't see this change.

The injection of an empty collection would be pretty much always an error in our application. Can you recommend a way to implement a safety net for this case?

At the moment i can see two possible ways to do this:

1. Use an own ConstructorResolver. This would result in much duplicated code as it is not visible to the application.
2. Implement a BeanPostProcessor which does this check via reflection.

Both seem to me more like a workaround (or rather a hack). It would be nice to have this behavior configurable. AbstractAutowireCapableBeanFactory could probably be a good spot for such a flag.

[jhoeller]

Why not simply put a custom assertion into your constructors where the incoming collections must not be empty? That way each such constructor may decide upon its expected state. I see that as generally recommendable since those constructors may also be called from outside of the framework, e.g. programmatically built, and should validate their incoming configuration state in any case.

[therob]

The only points i have against this solution is that it can be forgotten and this validation is done by the framework for other dependencies. I use the injection of collections to get different strategies which get dynamically selected at runtime. Currently we have no use case in our application where it would make sense to have no strategy.