Why DefaultListableBeanFactory causing bean creation loop in Tomcat

[Jehan Jaleel]

I have a Spring based web application that I am trying to load in my local Tomcat. (Spring 3.0.5, Tomcat 6)

Right now when the application is starting up on Tomcat, while it is trying to initialize the Spring Web application context, it is going into an infinite loop trying to create the beans I have defined in my XML config files. For example one of the beans bathTransactionManager, you can see below how it gets created and destroyed over and over again...

2013-07-10 16:44:01 DefaultListableBeanFactory [INFO] Pre-instantiating singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@72c8e15d: defining beans [bathTransactionManager]; parent: org.springframework.beans.factory.support.DefaultListableBeanFactory@30d06c9b
2013-07-10 16:44:01 DefaultListableBeanFactory [DEBUG] Creating shared instance of singleton bean 'bathTransactionManager'
2013-07-10 16:44:01 DefaultListableBeanFactory [DEBUG] Creating instance of bean 'bathTransactionManager'
2013-07-10 16:44:01 DefaultListableBeanFactory [DEBUG] Eagerly caching bean 'bathTransactionManager' to allow for resolving potential circular references
2013-07-10 16:44:01 DefaultListableBeanFactory [DEBUG] Invoking afterPropertiesSet() on bean with name 'bathTransactionManager'
2013-07-10 16:44:01 DefaultListableBeanFactory [DEBUG] Finished creating instance of bean 'bathTransactionManager'
2013-07-10 16:44:01 DefaultListableBeanFactory [DEBUG] Returning cached instance of singleton bean 'bathTransactionManager'
2013-07-10 16:44:02 DefaultListableBeanFactory [INFO] Destroying singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@4364ac55: defining beans [bathTransactionManager]; parent: org.springframework.beans.factory.support.DefaultListableBeanFactory@72c8e15d
2013-07-10 16:44:02 ClassPathXmlApplicationContextFactory$ResourceXmlApplicationContext [DEBUG] Bean factory for org.springframework.batch.core.configuration.support.ClassPathXmlApplicationContextFactory$ResourceXmlApplicationContext@210ee4c3: org.springframework.beans.factory.support.DefaultListableBeanFactory@4b47ce43: defining beans [bathTransactionManager]; parent: org.springframework.beans.factory.support.DefaultListableBeanFactory@72c8e15d
2013-07-10 16:44:02 DefaultListableBeanFactory [INFO] Pre-instantiating singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@4b47ce43: defining beans [bathTransactionManager]; parent: org.springframework.beans.factory.support.DefaultListableBeanFactory@72c8e15d
2013-07-10 16:44:02 DefaultListableBeanFactory [DEBUG] Creating shared instance of singleton bean 'bathTransactionManager'
2013-07-10 16:44:02 DefaultListableBeanFactory [DEBUG] Creating instance of bean 'bathTransactionManager'
2013-07-10 16:44:02 DefaultListableBeanFactory [DEBUG] Eagerly caching bean 'bathTransactionManager' to allow for resolving potential circular references
2013-07-10 16:44:02 DefaultListableBeanFactory [DEBUG] Invoking afterPropertiesSet() on bean with name 'bathTransactionManager'
2013-07-10 16:44:02 DefaultListableBeanFactory [DEBUG] Finished creating instance of bean 'bathTransactionManager'
2013-07-10 16:44:02 DefaultListableBeanFactory [DEBUG] Returning cached instance of singleton bean 'bathTransactionManager'
2013-07-10 16:44:03 DefaultListableBeanFactory [INFO] Destroying singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@79cd3761: defining beans [bathTransactionManager]; parent: org.springframework.beans.factory.support.DefaultListableBeanFactory@4b47ce43

Any ideas what is causing this?

Thanks in advance for any help.

[Jehan Jaleel]

One clue I have to the root of this problem is that the application context file imports beans from other config files like so...

  <import resource="classpath:/spring/quartz-job.xml"/>

Now in production (and in other developers' setup), these other config files are always in JARs within the lib folder. But what I did was deploy to Tomcat directly from MyEclipse and this caused the application to be in exploded format (so the config files are in the classes folder). When I deleted the files in the classes folder and imported the JARs, then the problem went away. But it is still strange. Why would the location of the files matter as long as it within the classpath?

Thanks.