Project background:
One day, there is a need to complete the project consolidation of two major projects in three days, because the package structure and class name of the previous two projects are much the same, and then began to consider using the Add-level package for isolation, similar to this structure
However, during the startup process, the exception is thrown:
Caused by:org.springframework.context.annotation.ConflictingBeanDefinitionException:annotation-specified Bean name ' nameconflict ' for Bean class [xom.liuyun.beannameconflict.modelB.NameConflict] Conflicts with existing, non-compatible bean definition of same name and class [Xom.liuyun.beannameconflict.modelA.NameCo Nflict]At Org.springframework.context.annotation.ClassPathBeanDefinitionScanner.checkCandidate ( classpathbeandefinitionscanner.java:348) ~[spring-context-5.0.4.release.jar:5.0.4.release]at Org.springframework.context.annotation.ClassPathBeanDefinitionScanner.doScan ( classpathbeandefinitionscanner.java:286) ~[spring-context-5.0.4.release.jar:5.0.4.release]at Org.springframework.context.annotation.ComponentScanAnnotationParser.parse (Componentscanannotationparser.java : ~[spring-context-5.0.4.release.jar:5.0.4.release]at) Org.springframework.context.annotation.ConfigurationClassParser.doProcessConfigurationClass ( configurationclassparser.java:284) ~[spring-context-5.0.4.release.jar:5.0.4.release]at Org.springframework.context.annotation.ConfigurationClassParser.processConfigurationClass ( configurationclassparser.java:241) ~[spring-context-5.0.4.release.jar:5.0.4.release]at Org.springframework.context.annotation.ConfigurationClassParser.parse (configurationclassparser.java:198) ~[ spring-context-5.0.4.release.jar:5.0.4.release]at Org.springframework.context.annotation.ConfigurationClassParser.parse ( configurationclassparser.java:166) ~[spring-context-5.0.4.release.jar:5.0.4.release] ... Common frames omitted.
Reason:
Spring provides two beanname generation strategies, annotation-based sprong-boot is annotationbeannamegenerator by default, and the strategy for generating beanname is to Take the current class name (not the fully qualified class name) as the Beanname. As a result, conflicts can occur if the same class name is present under different package structures.
The solution is as follows:
1. Write a class to implement the Org.springframework.beans.factory.support.BeanNameGeneraot interface
public class Uniquenamegenerator extends Annotationbeannamegenerator { @Override public String Generatebeanname (beandefinition definition, beandefinitionregistry registry) { //Fully qualified class name String beanname = Definition.getbeanclassname (); return beanname;} }
2. Annotate @componentscan (namegenerator = Uniquenamegenerator.class) on the startup class to make the Beanname generation policy that we just customized take effect.
@SpringBootApplication @componentscan (namegenerator = uniquenamegenerator.class) public class beannameconflictapplication {public static void main (string[] args) {Springapplication.run ( Beannameconflictapplication.class, args);}}
In this way, the problem can be solved.
Talk about spring-boot under different packet structure, the same class name conflict causes the service start failure solution