Package org.springframework.web.context.support

Class AnnotationConfigWebApplicationContext

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
org.springframework.web.context.support.AnnotationConfigWebApplicationContext
All Implemented Interfaces:
Closeable, AutoCloseable, Aware, BeanFactory, BeanNameAware, HierarchicalBeanFactory, InitializingBean, ListableBeanFactory, AnnotationConfigRegistry, ApplicationContext, ApplicationEventPublisher, ConfigurableApplicationContext, Lifecycle, MessageSource, EnvironmentCapable, ResourceLoader, ResourcePatternResolver, ThemeSource, ConfigurableWebApplicationContext, WebApplicationContext
public class AnnotationConfigWebApplicationContext extends AbstractRefreshableWebApplicationContext implements AnnotationConfigRegistry
WebApplicationContext implementation which accepts component classes as input — in particular @Configuration classes, but also plain @Component classes as well as JSR-330 compliant classes using jakarta.inject annotations.

Allows for registering classes one by one (specifying class names as config locations) as well as via classpath scanning (specifying base packages as config locations).

This is essentially the equivalent of AnnotationConfigApplicationContext for a web environment. However, in contrast to AnnotationConfigApplicationContext, this class does not extend GenericApplicationContext and therefore does not provide some of the convenient registerBean(...) methods available in a GenericApplicationContext. If you wish to register annotated component classes with a GenericApplicationContext in a web environment, you may use a GenericWebApplicationContext with an AnnotatedBeanDefinitionReader. See the Javadoc for GenericWebApplicationContext for details and an example.

To make use of this application context, the "contextClass" context-param for ContextLoader and/or "contextClass" init-param for FrameworkServlet must be set to the fully-qualified name of this class.

As of Spring 3.1, this class may also be directly instantiated and injected into Spring's DispatcherServlet or ContextLoaderListener when using the WebApplicationInitializer code-based alternative to web.xml. See its Javadoc for details and usage examples.

Unlike XmlWebApplicationContext, no default configuration class locations are assumed. Rather, it is a requirement to set the "contextConfigLocation" context-param for ContextLoader and/or "contextConfigLocation" init-param for FrameworkServlet. The param-value may contain both fully-qualified class names and base packages to scan for components. See loadBeanDefinitions(org.springframework.beans.factory.support.DefaultListableBeanFactory) for exact details on how these locations are processed.

As an alternative to setting the "contextConfigLocation" parameter, users may implement an ApplicationContextInitializer and set the "contextInitializerClasses" context-param / init-param. In such cases, users should favor the AbstractApplicationContext.refresh() and scan(String...) methods over the AbstractRefreshableConfigApplicationContext.setConfigLocation(String) method, which is primarily for use by ContextLoader.

Note: In case of multiple @Configuration classes, later @Bean definitions will override ones defined in earlier loaded files. This can be leveraged to deliberately override certain bean definitions via an extra @Configuration class.

Since:
3.0
Author:
Chris Beams, Juergen Hoeller, Sam Brannen
See Also: