SPRINGMVC conflicts with existing, non-compatible bean definition of same name and class solutions

Cause of the problem

Recently, the project team's colleagues encountered a problem, his own module, SPRINGMVC controller and other modules of the Controller class name, resulting in the entire project is not up.

The error in the background report is this:

At lunchtime, he complained to me about the problem and said he couldn't find a way.

After I think about it, SPRINGMVC's controller should be handled with a similar key-value pair (key/value) mapping method. In the middle of the key, the default is to use the Cotroller class name (not the full class name) as the key. Thus, if the names of the two contoller under the different packages are the same, it will cause the key in the controller map in SPRINGMVC's container management to be duplicated.

It's easier to solve this problem.

In @controller, it is possible to use duplicate names.

Here's an example:

Test.controller.bill. Billsavecontroller

 PackageTest.controller.bill;ImportOrg.springframework.stereotype.Controller;Importorg.springframework.web.bind.annotation.RequestMapping;/*** Created by Liuch on 5/27/15.*/@Controller @requestmapping ("/billsave") Public classBillsavecontroller {@RequestMapping ("/dosave")     PublicString Savebill () {return"Billsave"; }}

and Test.controller.bill.BillSaveController

 PackageTest.controller.billsave;ImportOrg.springframework.stereotype.Controller;Importorg.springframework.web.bind.annotation.RequestMapping;/*** Created by Liuch on 5/27/15.*/@Controller @requestmapping ("/billsave_test") Public classBillsavecontroller {@RequestMapping ("/test")     PublicString Test () {return"Test"; }}

The above two code, although under different packages, namely the full class name is different, but the class name is the same.

This way, when Tomcat starts, the background will error:

Severe:context Initialization failedorg.springframework.beans.factory.BeanDefinitionStoreException: Unexpected exception parsing XML document from ServletContext resource[/web-inf/dispatcher-servlet.xml]; Nested exception is java.lang.IllegalStateException:Annotationforclass  [ Test.controller.billsave.BillSaveController] conflicts with existing, non-class [ Test.controller.bill.BillSaveController]

Cause of the problem:

Because if you do not use a name when using annotations @Controller, SPRINGMVC defaults to lowercase the first letter of the class name, and then puts it in a map.

For example above, although the above two classes all have different names, they use the @controller annotations without naming. When the SPRINGMVC scan the controller, they will be resolved to Billsavecontroller by default. Then take this billsavecontroller as the key (key) and put it in a global map.

In this way, there will be two keys exactly the same controller. Because SPRINGMVC does not use overrides to process controllers with different full-class names with the same key, the error is covered in the scan.

The solution:

Use the name on @controller

such as: in Test.controller.bill.BillSaveController

 PackageTest.controller.bill;ImportOrg.springframework.stereotype.Controller;Importorg.springframework.web.bind.annotation.RequestMapping;/*** Created by Liuch on 5/27/15.*/@Controller ("Testbillsave" )@RequestMapping ("/billsave") Public classBillsavecontroller {@RequestMapping ("/dosave")     PublicString Savebill () {return"Billsave"; }}

In Test.controller.billsave.BillSaveController, use:

 PackageTest.controller.billsave;ImportOrg.springframework.stereotype.Controller;Importorg.springframework.web.bind.annotation.RequestMapping;/*** Created by Liuch on 5/27/15.*/@Controller ("Realbillsave" )@RequestMapping ("/billsave_test") Public classBillsavecontroller {@RequestMapping ("/test")     PublicString Test () {return"Test"; }}

The above two controllers, as long as a name can be guaranteed, but the best of two are used.

This is a good way to program because you cannot guarantee that others will not use the same name as your controller.

Postscript:

This afternoon let colleagues try, sure enough.

SPRINGMVC conflicts with existing, non-compatible bean definition of same name and class solutions