There’s nothing special about the file named “applicationContext.xml” except that it’s the name Spring tends to expect as its default configuration file. Using one file named that or multiple files named “dog.xml”, “cat.xml”, and “alien.xml” will work exactly the same way. The trouble you’re having comes from having multiple ApplicationContexts in use at the same time, not from having multiple XML files. I’ve recently answered a couple of questions from people who had problems caused by not understanding these concepts. Check out those answers, and see what questions you still have:
Declaring Spring Bean in Parent Context vs Child Context
Spring-MVC: What are a “context” and “namespace”?
Edit: In response to your new question:
I had a
<context:component-scan base-package="com.myapp"/>tag in my servlet.xml.
I’m guessing this “servlet.xml” file is named like foo-servlet.xml, where the DispatcherServlet configured in your web.xml is named “foo”, like
<servlet>
<servlet-name>foo</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
</servlet>
By convention, when this DispatcherServlet starts, it’ll create a new ApplicationContext that’s configured by the file foo-servlet.xml, derived from the servlet-name. Now, since you put a context:component-scan in there, it’s going to recursively scan the given package and create beans for all annotated classes. The package you gave it, com.myapp, looks like it’s the base package for your entire app, so Spring will create beans from all of the annotated classes in your app, including the data access ones, in this one ApplicationContext that’s associated to the DispatcherServlet. Typically, this context should only have view-layer stuff and beans that directly support the DispatcherServlet in it, so this was something of a misconfiguration.
In my data.xml file I had data source beans and that was it. No other beans, everything else was autowired and annotated.
Presumably, this “data.xml” file is the one you listed in the contextConfigLocation context-param. Assuming you’d also added the ContextLoaderListener to your web.xml, like
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
then that file will be used to create a second ApplicationContext–the root context. That’s what this listener does. Note that it actually builds the context from all the files listed in contextConfigLocation, and if you also included your “servlet.xml” in that list, then you’ve loaded that config twice: here in the root context as well as in the context associated with the DipatcherServlet. Hopefully you see now how there’s a distinct division between the XML configuration files and the ApplicationContexts that they configure. The same XML file can easily be used to configure two different contexts. Whether doing so is correct or not is another question. In this particular case, it isn’t.
The order I’ve described these two contexts in is actually backwards. I was just following your description of what you did. The ContextLoaderListener, being a ServletContextListener, will always execute before any servlet starts up. This means the root context is created first, and the other context second. This is by design so that when the DispatcherServlet creates its context, it can add that context as a child of the root context. I’ve described this relationship in those other posts. The most important effect of this is that beans in the root context are available to and via the DispatcherServlet’s context. That applies to autowired relationships, too. That’s important because the DispatcherServlet only looks in its associated context for beans that it needs, like controller instances. Your controllers, though, obviously have to be wired with supporting beans. Thus, traditionally, the controllers live in the DispatcherServlet’s context, and the supporting beans live in the root context.
I then tried to add @Transacational to my service bean and it wouldn’t persist.
In order for @Transactional to work, you must include the <tx:annotation-driven/> tag in the configuration of the ApplicationContext where the annotated bean lives. The trick is figuring out the “where it lives” part. Beans in a child can override beans in a parent context. Therefore–I’m just guessing here–if you loaded all your beans into the DispatcherServlet context as I described above but put the <tx:annotation-driven/> in the root context, you might have a bean in the root context that’s correctly transactional, but it’s not the one being used because the duplicate is “closer” to the servlet in the parent/child hierarchy, and the context it’s in didn’t get a <tx:annotation-driven/> configuration.
When I changed the servlet context:component-scan tag to instead point at com.myapp.web and then added a context:component-scan tag to the data.xml file, everything worked.
It still depends somewhat on exactly which config files you were including in which ApplicationContexts, but at the very least I can say that by doing this, you removed a lot of beans from the DispatcherServlet’s context which were causing problems. In particular, your correctly-configured @Transactional beans in the root context would no longer be shadowed by beans in the child context and would be injected into your controllers, so your persistence stuff would work then.
So… the main thing to take away is that you have two related ApplicationContexts. You have to remain aware of that fact and stay in control of which beans go in which context.
Does that cover everything?