Closed spring-projects-issues closed 7 years ago
Juergen Hoeller commented
Indeed, the container is trying to resolve a Map
from bean names to value beans here, composed of your individual Integer
beans. Unfortunately, this currently kicks in for any Map
type, even if the specific signature isn't compatible. I'll refine this for 4.3.6.
If you remove those individual Integer
beans, constructing them inline within the someBiMap()
method instead, @Autowired
resolution should work fine as well: Since the container cannot find corresponding value beans anymore, it'll skip that code path to begin with.
Sotirios Delimanolis opened SPR-15117 and commented
This issue follows the findings in this Stack Overflow question.
Consider the following
The expect behavior is for the bean named
someBiMap
to be injected in theTestControl
constructor.Instead, we get a
BeanInstantiationException
We can work around this by qualifying the parameter name
or using using field injection with
@Resource
and the appropriate name, assuming the field is non-final
.However, the documentation states
which makes me think this is a bug. The resolution for a
Map
of bean names to beans seems to take precedence over the resolution by type.Affects: 4.3.2
Issue Links:
18536 Optional autowire of Map<String, BeanType> accidentally falls back to unrelated Map<String, String>
12570 Allow for normal bean wiring semantics for types assignable to Map