Java Doc for GenericApplicationContext.java in  » J2EE » spring-framework-2.0.6 » org » springframework » context » support » Java Source Code / Java DocumentationJava Source Code and Java Documentation

Typical usage is to register a variety of bean definitions via the org.springframework.beans.factory.support.BeanDefinitionRegistry interface and then call GenericApplicationContext.refresh() to initialize those beans with application context semantics (handling org.springframework.context.ApplicationContextAware , auto-detecting org.springframework.beans.factory.config.BeanFactoryPostProcessor BeanFactoryPostProcessors , etc).

In contrast to other ApplicationContext implementations that create a new internal BeanFactory instance for each refresh, the internal BeanFactory of this context is available right from the start, to be able to register bean definitions on it. GenericApplicationContext.refresh() may only be called once.

Usage example:

 GenericApplicationContext ctx = new GenericApplicationContext();
 XmlBeanDefinitionReader xmlReader = new XmlBeanDefinitionReader(ctx);
 xmlReader.loadBeanDefinitions(new ClassPathResource("applicationContext.xml"));
 PropertiesBeanDefinitionReader propReader = new PropertiesBeanDefinitionReader(ctx);
 propReader.loadBeanDefinitions(new ClassPathResource("otherBeans.properties"));
 ctx.refresh();
 MyBean myBean = (MyBean) ctx.getBean("myBean");
 ...

For custom application context implementations that are supposed to read special bean definition formats in a refreshable manner, consider deriving from the AbstractRefreshableApplicationContext base class.
author:
   Juergen Hoeller
since:
   1.1.2
See Also:   GenericApplicationContext.registerBeanDefinition
See Also:   GenericApplicationContext.refresh()
See Also:   org.springframework.beans.factory.xml.XmlBeanDefinitionReader
See Also:   org.springframework.beans.factory.support.PropertiesBeanDefinitionReader

NOTE: You need to call GenericApplicationContext.refresh() to initialize the bean factory and its contained beans with application context semantics (autodetecting BeanFactoryPostProcessors, etc). the internal bean factory (as DefaultListableBeanFactory)

The main reason to specify a custom ResourceLoader is to resolve resource paths (withour URL prefix) in a specific fashion. The default behavior is to resolve such paths as class path locations. To resolve resource paths as file system locations, specify a FileSystemResourceLoader here.

You can also pass in a full ResourcePatternResolver, which will be autodetected by the context and used for getResources calls as well. Else, default resource pattern matching will apply.
See Also:   GenericApplicationContext.getResource
See Also:   org.springframework.core.io.DefaultResourceLoader
See Also:   org.springframework.core.io.FileSystemResourceLoader
See Also:   org.springframework.core.io.support.ResourcePatternResolver
See Also:   GenericApplicationContext.getResources