Here's how I think this story begins: Philip started learning Spring by creating a Spring
Java app, and configured his Application Context like this:
with the .xml file residing on the classpath (because there is nowhere else to put it).
Then he tried to cross-pollenate a Spring WebMVC app using the same logic, without fully understanding how to configure a "web Application Context".
According to Spring documentation
Spring 4.3.7 , on page 156:
You can create ApplicationContext instances declaratively by using, for example, a
ContextLoader. Of course you can also create ApplicationContext instances programmatically
by using one of the ApplicationContext implementations.
You can register an ApplicationContext using the ContextLoaderListener as follows:
The listener inspects the contextConfigLocation parameter. If the parameter does not exist, the
listener uses /WEB-INF/applicationContext.xml as a default. When the parameter does exist,
the listener separates the String by using predefined delimiters (comma, semicolon and whitespace)
and uses the values as locations where application contexts will be searched. Ant-style path patterns
are supported as well. Examples are /WEB-INF/*Context.xml for all files with names ending with
"Context.xml", residing in the "WEB-INF" directory, and /WEB-INF/**/*Context.xml, for all such
files in any subdirectory of "WEB-INF".
The ContextLoaderListener class in web.xml will bootstrap the "web Application Context" via the .xml file(s) in the WEB-INF folder.
So, Paul is correct saying the .xml path is relative to "which Application Context interface is being implemented", and Philip COULD use the classpath, but Spring documentation implies
you SHOULD use the WEB-INF folder.