This is a public information broadcast for the benefit of developers using Spring MVC with annotation-driven configuration.
I was a bit stumped earlier by this error on startup of my web application:
java.lang.IllegalStateException: Annotation-specified bean name ‘enterOrderNumberController’ for bean class [uk.ac.bham.ework.eb.controllers.EnterOrderNumberController] conflicts with existing, non-compatible bean definition of same name and class [uk.ac.bham.ework.eb.controllers.bookingoperations.EnterOrderNumberController]
followed by a lovely stack trace. The webapp had been running fine locally, but died as soon as I copied it across to the test server. Here is the explanation. Look carefully at those two class names in the first line again:
- uk.ac.bham.ework.eb.controllers.EnterOrderNumberController
- uk.ac.bham.ework.eb.controllers.bookingoperations.EnterOrderNumberController
Not the same, are they? I had been doing a little neatening-up, moving EnterOrderNumberController into a different package. On my local box, the IDE had kindly deleted the compiled version of uk.ac.bham.ework.eb.controllers.EnterOrderNumberController from WEB-INF/classes. On the test server, I had done an svn update and then just run the Ant build script, and my not-very-well-written build.xml had not cleaned up the debris from previous builds.
So I had two classes called EnterOrderNumberController in my classpath, and Spring was trying to instantiate both, but finding they both needed the same bean name, which wasn’t allowed. The solution was to get rid of the old, now-superfluous one.
The build script has now been modified.
Thank you for listening to this public information broadcast.
Richard Huss's Weblog 
thank you! I hadnt thought of that, and it was exactly what was causing my problem
Thanks for pointing out the cause of this error. I necountered it in similar circumstances, the problem though was different: The Tomcat server I’d copied the file to hadn’t cleared its work folders properly so I deleted them and restarted Tomcat and the problem was solved. Still not sure why this class got loaded at all though.
This was to the point and helped me debug the classpath problem in one minute (I missed the fact that the classes belonged to different packages). Thanks.
Glad to be of assistance; ironically I spent yesterday planning the removal of all this code!
Thanks, you pointed me to the right direction!
In my case the fix was to change tomcat config (server.xml) unpackWARs=”false” to unpackWARs=”true”.
Glad to be able to help – my code has now gone to the great code graveyard in the sky!