WebApplicationContext implementation that takes configuration from an XML document,
understood by an XmlBeanDefinitionReader. This is essentially the equivalent of
AbstractXmlApplicationContext and its subclasses for a web environment.
By default, the configuration will be taken from "/WEB-INF/applicationContext.xml"
for the root context, and "/WEB-INF/test-servlet.xml" for a context with the namespace
"test-servlet" (like for a DispatcherServlet instance with the servlet-name "test").
The config location defaults can be overridden via the "contextConfigLocation"
context param of ContextLoader and servlet param of FrameworkServlet. Config locations
can either denote concrete files like "/WEB-INF/context.xml" or Ant-style patterns
like "/WEB-INF/*-context.xml" (see PathMatcher javadoc for pattern details).
Note: In case of multiple config locations, later bean definitions will
override ones defined in earlier loaded files. This can be leveraged to
deliberately override certain bean definitions via an extra XML file.
For a WebApplicationContext that reads in a different bean definition format,
create an analogous subclass of AbstractRefreshableWebApplicationContext.
Such a context implementation can be specified as "contextClass" context-param
for ContextLoader or "contextClass" init-param for FrameworkServlet.
By default, the configuration will be taken from "/WEB-INF/applicationContext.xml" for the root context, and "/WEB-INF/test-servlet.xml" for a context with the namespace "test-servlet" (like for a DispatcherServlet instance with the servlet-name "test").
The config location defaults can be overridden via the "contextConfigLocation" context param of ContextLoader and servlet param of FrameworkServlet. Config locations can either denote concrete files like "/WEB-INF/context.xml" or Ant-style patterns like "/WEB-INF/*-context.xml" (see PathMatcher javadoc for pattern details).
Note: In case of multiple config locations, later bean definitions will override ones defined in earlier loaded files. This can be leveraged to deliberately override certain bean definitions via an extra XML file.
For a WebApplicationContext that reads in a different bean definition format, create an analogous subclass of AbstractRefreshableWebApplicationContext. Such a context implementation can be specified as "contextClass" context-param for ContextLoader or "contextClass" init-param for FrameworkServlet.