Class AbstractRefreshableWebApplicationContext

java.lang.Object
org.springframework.core.io.DefaultResourceLoader
org.springframework.context.support.AbstractApplicationContext
org.springframework.context.support.AbstractRefreshableApplicationContext
org.springframework.context.support.AbstractRefreshableConfigApplicationContext
org.springframework.web.context.support.AbstractRefreshableWebApplicationContext
All Implemented Interfaces:
Closeable, AutoCloseable, Aware, BeanFactory, BeanNameAware, HierarchicalBeanFactory, InitializingBean, ListableBeanFactory, ApplicationContext, ApplicationEventPublisher, ConfigurableApplicationContext, Lifecycle, MessageSource, EnvironmentCapable, ResourceLoader, ResourcePatternResolver, ConfigurableWebApplicationContext, WebApplicationContext
Direct Known Subclasses:
AnnotationConfigWebApplicationContext, GroovyWebApplicationContext, XmlWebApplicationContext
public abstract class AbstractRefreshableWebApplicationContext extends AbstractRefreshableConfigApplicationContext implements ConfigurableWebApplicationContext
AbstractRefreshableApplicationContext subclass which implements the ConfigurableWebApplicationContext interface for web environments. Provides a "configLocations" property, to be populated through the ConfigurableWebApplicationContext interface on web application startup.

This class is as easy to subclass as AbstractRefreshableApplicationContext: All you need to implement is the AbstractRefreshableApplicationContext.loadBeanDefinitions(DefaultListableBeanFactory) method; see the superclass javadoc for details. Note that implementations are supposed to load bean definitions from the files specified by the locations returned by the getConfigLocations() method.

Interprets resource paths as servlet context resources, i.e. as paths beneath the web application root. Absolute paths, for example, for files outside the web app root, can be accessed via "file:" URLs, as implemented by DefaultResourceLoader.

This is the web context to be subclassed for a different bean definition format. Such a context implementation can be specified as "contextClass" context-param for ContextLoader or as "contextClass" init-param for FrameworkServlet, replacing the default XmlWebApplicationContext. It will then automatically receive the "contextConfigLocation" context-param or init-param, respectively.

Note that WebApplicationContext implementations are generally supposed to configure themselves based on the configuration received through the ConfigurableWebApplicationContext interface. In contrast, a standalone application context might allow for configuration in custom startup code (for example, GenericApplicationContext).

Since:
1.1.3
Author:
Juergen Hoeller
See Also: