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

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

Open
spring-projects-issues opened this issue Sep 3, 2016 · 2 comments
Open
Labels
in: core type: enhancement

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Sep 3, 2016

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:

  • #15434 Reconsider whether to generally allow bean overriding by name
@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Apr 4, 2017

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Apr 4, 2017

Caleb Cushing commented

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core type: enhancement
Projects
None yet
Development

No branches or pull requests

1 participant