Class 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-annotated classes, but also plain @Component classes and JSR-330 compliant classes using jakarta.inject annotations.

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

This is essentially the equivalent of AnnotationConfigApplicationContext for a web environment.

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

Chris Beams, Juergen Hoeller
See Also: