Description
Juergen Hoeller opened SPR-14965 and commented
Introducing self reference injection in 4.3, the revision of the algorithm accidentally also choses a self reference as a fallback element for an empty collection injection point. Of course, self references were only meant to be used as a direct dependency declaration, not as a collection element. This is also what the documentation and the existing test cases suggest.
A collection of the same type can be used for aggregates, e.g. propagating an event to listeners, with the aggregate also implementing the listener interface itself. This still works fine if there are delegate listener beans in the context but unfortunately fails as of 4.3 when the collection is declared as optional and meant to remain uninjected if no delegates are found, since all of a sudden there is a single-element collection with a self reference to the aggregate... This is a regression that needs to be fixed as of 4.3.5; better late than never.
Affects: 4.3.4
Issue Links:
- Optional autowire of Map<String, BeanType> accidentally falls back to unrelated Map<String, String> [SPR-13963] #18536 Optional autowire of Map<String, BeanType> accidentally falls back to unrelated Map<String, String>
- Support @Autowired-like self injection [SPR-8450] #13096 Support
@Autowired-likeself injection - @Autowired does not work for target bean of type Collection [SPR-12180] #16794
@Autowireddoes not work for target bean of type Collection - Behaviour of field injection for List dependencies that are produced and consumed by the same configuration class has changed in 4.3.5 snapshots [SPR-14996] #19563 Behaviour of field injection for List dependencies that are produced and consumed by the same configuration class has changed in 4.3.5 snapshots