Auto-resolve bean name conflicts for scanned classes [SPR-14665]

[spring-projects-issues]

Caleb Cushing opened SPR-14665 and commented

so let's say I have two WebSecurityConfig classes which extend WebSecurityConfigurerAdapter. You will get a conflict like this

nested exception is org.springframework.context.annotation.ConflictingBeanDefinitionException: Annotation-specified bean name 'webSecurityConfig' for bean class [com.xenoterracide.rpf.security.config.WebSecurityConfig] conflicts with existing, non-compatible bean definition of same name and class [com.xenoterracide.rpf.config.WebSecurityConfig]

this of course would be even worse if they were in jars you didn't control the source for (not that I've ever encountered that).

It occurs to me that I never need to use name injection for these. Perhaps spring could auto name them including the package name... or some other unique method (or perhaps do away with the name requirement?). Basically the idea is if you want a user friendly name to inject that you can still specify one.

This probably does break backwards compatibility so maybe it could be part of 5 if possible.

---

Issue Links:

• Reconsider whether to generally allow bean overriding by name [SPR-10808] #15434 Reconsider whether to generally allow bean overriding by name

[spring-projects-issues]

Juergen Hoeller commented

While bean names may not matter during such a component scan, they may matter for explicit overrides later on. During a component scan, such overlapping names may indicate an intended override arrangement that we do not accept during an (unordered) scan. The same arrangement may work fine with explicit (ordered) definitions, so it seems unintuitive to silently register them side by side (with automatically adapted bean names) during a scan. You do have a point that such an arrangement could be accepted in general; I just wonder whether it is a natural outcome in the default Spring bean definition model.

You could of course specify a custom BeanNameGenerator for your scan and use more unique bean names, e.g. the fully-qualified class name.

In any case, we're not going to get to any fundamental changes for 5.0 anymore. I'll put it into the backlog for further consideration (and further cases made by other stakeholders).

[spring-projects-issues]

Caleb Cushing commented

ok, thanks for looking into it, and the explanation.

[jhoeller]

With the option of resolving this through an explicitly configured BeanNameGenerator, we do not intend to auto-resolve such scenarios.