BeanFactory.java

    /*
     The root interface for accessing a Spring bean container.

    This is the basic client view of a bean container;
    further interfaces such as {@link ListableBeanFactory} and
     {@link org.springframework.beans.factory.config.ConfigurableBeanFactory}
    are available for specific purposes.

    This interface is implemented by objects that hold a number of bean definitions,
     each uniquely identified by a String name. Depending on the bean definition,
    the factory will return either an independent instance of a contained object
     (the Prototype design pattern), or a single shared instance (a superior
    alternative to the Singleton design pattern, in which the instance is a
     singleton in the scope of the factory). Which type of instance will be returned
    depends on the bean factory configuration: the API is the same. Since Spring
     2.0, further scopes are available depending on the concrete application
    context (e.g. “request” and “session” scopes in a web environment).

    The point of this approach is that the BeanFactory is a central registry
     of application components, and centralizes configuration of application
    components (no more do individual objects need to read properties files,
     for example). See chapters 4 and 11 of “Expert One-on-One J2EE Design and
    Development” for a discussion of the benefits of this approach.

    Note that it is generally better to rely on Dependency Injection
     (“push” configuration) to configure application objects through setters
    or constructors, rather than use any form of “pull” configuration like a
     BeanFactory lookup. Spring’s Dependency Injection functionality is
    implemented using this BeanFactory interface and its subinterfaces.

    Normally a BeanFactory will load bean definitions stored in a configuration
     source (such as an XML document), and use the {@code org.springframework.beans}
    package to configure the beans. However, an implementation could simply return
     Java objects it creates as necessary directly in Java code. There are no
    constraints on how the definitions could be stored: LDAP, RDBMS, XML,
     properties file, etc. Implementations are encouraged to support references
    amongst beans (Dependency Injection).

    In contrast to the methods in {@link ListableBeanFactory}, all of the
     operations in this interface will also check parent factories if this is a
    {@link HierarchicalBeanFactory}. If a bean is not found in this factory instance,
     the immediate parent factory will be asked. Beans in this factory instance
    are supposed to override beans of the same name in any parent factory.

    Bean factory implementations should support the standard bean lifecycle interfaces
     as far as possible. The full set of initialization methods and their standard order is:
    1. BeanNameAware’s {@code setBeanName}
    2. BeanClassLoaderAware’s {@code setBeanClassLoader}
    3. BeanFactoryAware’s {@code setBeanFactory}
    4. EnvironmentAware’s {@code setEnvironment}
    5. EmbeddedValueResolverAware’s {@code setEmbeddedValueResolver}
    6. ResourceLoaderAware’s {@code setResourceLoader}
       (only applicable when running in an application context)
    7. ApplicationEventPublisherAware’s {@code setApplicationEventPublisher}
       (only applicable when running in an application context)
    8. MessageSourceAware’s {@code setMessageSource}
       (only applicable when running in an application context)
    9. ApplicationContextAware’s {@code setApplicationContext}
       (only applicable when running in an application context)
    10. ServletContextAware’s {@code setServletContext}
       (only applicable when running in a web application context)
    11. {@code postProcessBeforeInitialization} methods of BeanPostProcessors
    12. InitializingBean’s {@code afterPropertiesSet}
    13. a custom {@code init-method} definition
    14. {@code postProcessAfterInitialization} methods of BeanPostProcessors


    On shutdown of a bean factory, the following lifecycle methods apply:


    1. {@code postProcessBeforeDestruction} methods of DestructionAwareBeanPostProcessors
    2. DisposableBean’s {@code destroy}
    3. a custom {@code destroy-method} definition


    @author Rod Johnson
    @author Juergen Hoeller
     @author Chris Beams
    @since 13 April 2001
     @see BeanNameAware#setBeanName
    @see BeanClassLoaderAware#setBeanClassLoader
     @see BeanFactoryAware#setBeanFactory
    @see org.springframework.context.EnvironmentAware#setEnvironment
     @see org.springframework.context.EmbeddedValueResolverAware#setEmbeddedValueResolver
    @see org.springframework.context.ResourceLoaderAware#setResourceLoader
     @see org.springframework.context.ApplicationEventPublisherAware#setApplicationEventPublisher
    @see org.springframework.context.MessageSourceAware#setMessageSource
     @see org.springframework.context.ApplicationContextAware#setApplicationContext
    @see org.springframework.web.context.ServletContextAware#setServletContext
     @see org.springframework.beans.factory.config.BeanPostProcessor#postProcessBeforeInitialization
    @see InitializingBean#afterPropertiesSet
     @see org.springframework.beans.factory.support.RootBeanDefinition#getInitMethodName
    @see org.springframework.beans.factory.config.BeanPostProcessor#postProcessAfterInitialization
     @see org.springframework.beans.factory.config.DestructionAwareBeanPostProcessor#postProcessBeforeDestruction
    @see DisposableBean#destroy
     @see org.springframework.beans.factory.support.RootBeanDefinition#getDestroyMethodName
    */