How to Debug Spring NoSuchBeanDefinitionException

Question

We have a (non-web app) Spring application that throws a NoSuchBeanDefinitionException when running tests on our CruiseControl continuous integration linux box. The test runs fine on Windows in Eclipse.

The exception is thrown on the getBean() method:

ApplicationContext context = new ClassPathXmlApplicationContext(CONTEXT_FILE);

MyBean bean = (MyBean)context.getBean("myBean");

The context file is rather large and complicated. The context file is in the classpath and Spring is finding it. I'd prefer it if Spring would throw an exception when trying to load the context file and build the dependencies so that we could have an idea as to where to start. Is there a way to force Spring to throw an exception at the time of creating the context?

Solution 1

Solved. The instantiation of "myBean" in CONTEXT_FILE occurred after another bean that depended on it. This really should not be an issue, but I suspect that the parser on the Linux box must be stricter. Anyway, changing the order of definitions made it work on both Windows and Linux.

Solution 2

Are you certain that there is a bean named "myBean" in the CONTEXT_FILE? Are you using more than one context file? Have you turned up the Spring's logging to verify that the CONTEXT_FILE is being loaded correctly, and furthermore, than the file Spring is loading from the classpath is the exact file you think it should be loading?

I think you might be looking for the wrong solution to your problem - I've never seen Spring throw a NoSuchBeanDefinitionException except for the case where the bean you are asking for is not defined in the context, simple as that.

Solution 3

I had the same problem. It turned out that it was a subtle classpath issue. Specifically - my classpath on linux was set up so that my config directory containing my build.xml file came after my x-jars (external jars) directory - and some other beans.xml was being picked up from my x-jars which, as the log message correctly said, did not contain the required bean. It would have helped if the full path to the beans.xml file had been loggged with the Spring error message.