Class AbstractRefreshableWebApplicationContext

All Implemented Interfaces:
Closeable, AutoCloseable, Aware, BeanFactory, BeanNameAware, HierarchicalBeanFactory, InitializingBean, ListableBeanFactory, ApplicationContext, ApplicationEventPublisher, ConfigurableApplicationContext, Lifecycle, MessageSource, EnvironmentCapable, ResourceLoader, ResourcePatternResolver, ThemeSource, ConfigurableWebApplicationContext, WebApplicationContext
Direct Known Subclasses:
AnnotationConfigWebApplicationContext, GroovyWebApplicationContext, XmlWebApplicationContext

public abstract class AbstractRefreshableWebApplicationContext extends AbstractRefreshableConfigApplicationContext implements ConfigurableWebApplicationContext, ThemeSource
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 implements is the AbstractRefreshableApplicationContext.loadBeanDefinitions( 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, e.g. for files outside the web app root, can be accessed via "file:" URLs, as implemented by DefaultResourceLoader.

In addition to the special beans detected by AbstractApplicationContext, this class detects a bean of type ThemeSource in the context, under the special bean name "themeSource".

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).

Juergen Hoeller
See Also: