spring IOC container starting twice

[solid]

Why does spring start twice when the contextLoadListener and disbatcher servlet are both configured in the web.xml?

More importantly, is there a way I can configure the disbatcher servlet to start up using the spring instance that is created by the contextloadlistener that already started?

[Amiag]

Hi , if I'm not mistaken, the DispatcherServlet automatically uses the web application context created by the contextLoadListener as parent for its own context, so you should be able to access the beans defined there.

[solid]

well I tried removing the contextConfigLocation init-param from the servlet config but then my app blows up with the following

javax.servlet.ServletException: Servlet.init() for servlet controllerServlet threw exception
	org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
	org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
	org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849)
	org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
	org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454)
	java.lang.Thread.run(Thread.java:619)

root cause

org.springframework.beans.factory.BeanDefinitionStoreException: IOException parsing XML document from ServletContext resource [/WEB-INF/controllerServlet-servlet.xml]; nested exception is java.io.FileNotFoundException: Could not open ServletContext resource [/WEB-INF/controllerServlet-servlet.xml]
	org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:341)
	org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:302)
	org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:143)
	org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:178)
	org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:149)
	org.springframework.web.context.support.XmlWebApplicationContext.loadBeanDefinitions(XmlWebApplicationContext.java:124)
	org.springframework.web.context.support.XmlWebApplicationContext.loadBeanDefinitions(XmlWebApplicationContext.java:93)
	org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:130)
	org.springframework.context.support.AbstractApplicationContext.obtainFreshBeanFactory(AbstractApplicationContext.java:465)
	org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:395)
	org.springframework.web.servlet.FrameworkServlet.createWebApplicationContext(FrameworkServlet.java:442)
	org.springframework.web.servlet.FrameworkServlet.createWebApplicationContext(FrameworkServlet.java:458)
	org.springframework.web.servlet.FrameworkServlet.initWebApplicationContext(FrameworkServlet.java:339)
	org.springframework.web.servlet.FrameworkServlet.initServletBean(FrameworkServlet.java:306)
	org.springframework.web.servlet.HttpServletBean.init(HttpServletBean.java:127)
	javax.servlet.GenericServlet.init(GenericServlet.java:212)
	org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
	org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
	org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849)
	org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
	org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454)
	java.lang.Thread.run(Thread.java:619)

I changed my servlet c onfig to the following

	<servlet>
		<servlet-name>controllerServlet</servlet-name>
		<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
	     <init-param>
			<param-name>contextConfigLocation</param-name>
			<param-value></param-value>
		</init-param>
	</servlet>

and that does seem to work. This seeems like it shouldn't be necessary though.

[Marten Deinum]

That is default behavior.

As explained the ContextLoaderListener loads the generic ApplicationContext and the DispatcherServlet loads its own ApplicationContext. The generic one should contain your Services, dao's, infrastructure and other general stuff. The one from the DispatcherServlet should load things only needed by the servlet like Views, ViewResolvers, HanderMappings, Controllers.

This is needed because it is good split your application that way. It doesn't load (luckily) everything in one big ApplicationContext or else on multiple projects I would have been in trouble. I used multiple DispatcherServlets and MessageDispatcherServlets and if it was aggregating everything together well bye bye application I could say.

The defaults are explained in the reference guide.

[solid]

what danger is posed by having your whole configuration in one file (assuming you are willing to deal with an extremely large xml file)?

[Marten Deinum]

I nowhere mentioned 1 file! I mentioned 1 big ApplicationContext.

ApplicationContext != 1 xml file.

A part from the fact that you should split your generic and web materials (although we can argue about that if you only have 1 DispatcherServlet) in the case where you have multiple (Message)DispatcherServlets that could become an issue. Why, unpredictable behavior due to certain beans are loaded by name (localeresolver, themresolver to name a few) and others by type. Now if you want to have multiple instances of those beans (due to various reasons) you aren't able if you hack everything into 1 large ApplicationContext.

On more then 1 occasion I needed this and it helped to have multiple (Message)DispatcherServlets. Each having just those things needed (converts, url mappings. interceptors etc.) and they shared the services from the generic applicationcontext (loaded only once).