anchor.diff:  [[beans-beanfactory]]
   == The BeanFactory
   
  -The `BeanFactory` provides the underlying basis for Spring's IoC functionality but it is
  -only used directly in integration with other third-party frameworks and is now largely
  -historical in nature for most users of Spring. The `BeanFactory` and related interfaces,
  -such as `BeanFactoryAware`, `InitializingBean`, `DisposableBean`, are still present in
  -Spring for the purposes of backward compatibility with the large number of third-party
  -frameworks that integrate with Spring. Often third-party components that can not use
  -more modern equivalents such as `@PostConstruct` or `@PreDestroy` in order to avoid a
  -dependency on JSR-250.
  -
  -This section provides additional background into the differences between the
  -`BeanFactory` and `ApplicationContext` and how one might access the IoC container
  -directly through a classic singleton lookup.
  +The `BeanFactory` API provides the underlying basis for Spring's IoC functionality.
  +Its specific contracts are mostly used in integration with other parts of Spring and
  +related third-party frameworks, and its `DefaultListableBeanFactory` implementation
  +is a key delegate within the higher-level `GenericApplicationContext` container.
  +
  +`BeanFactory` and related interfaces such as `BeanFactoryAware`, `InitializingBean`,
  +`DisposableBean` are important integration points for other framework components:
  +not requiring any annotations or even reflection, they allow for very efficient
  +interaction between the container and its components. Application-level beans may
  +use the same callback interfaces but will typically prefer declarative dependency
  +injection instead, either via annotations or through programmatic configuration.
  +
  +Note that the core `BeanFactory` API level and its `DefaultListableBeanFactory`
  +implementation do not make assumptions about the configuration format or any
  +component annotations to be used. All of these flavors come in through extensions
  +such as `XmlBeanDefinitionReader` and `AutowiredAnnotationBeanPostProcessor`,
  +operating on shared `BeanDefinition` objects as a core metadata representation.
  +This is the essence of what makes Spring's container so flexible and extensible.
  +
  +The following section explains the differences between the `BeanFactory` and
  +`ApplicationContext` container levels and the implications on bootstrapping.
   
   
   
   [[context-introduction-ctx-vs-beanfactory]]
   === BeanFactory or ApplicationContext?
   
  -Use an `ApplicationContext` unless you have a good reason for not doing so.
  -
  -Because the `ApplicationContext` includes all functionality of the `BeanFactory`, it is
  -generally recommended over the `BeanFactory`, except for a few situations such as in
  -embedded applications running on resource-constrained devices where memory consumption
  -might be critical and a few extra kilobytes might make a difference. However, for
  -most typical enterprise applications and systems, the `ApplicationContext` is what you
  -will want to use. Spring makes __heavy__ use of the <<beans-factory-extension-bpp,
  -`BeanPostProcessor` extension point>> (to effect proxying and so on). If you use only a
  -plain `BeanFactory`, a fair amount of support such as transactions and AOP will not take
  -effect, at least not without some extra steps on your part. This situation could be
  -confusing because nothing is actually wrong with the configuration.
  +Use an `ApplicationContext` unless you have a good reason for not doing so, with
  +`GenericApplicationContext` and its subclass `AnnotationConfigApplicationContext`
  +as the common implementations for custom bootstrapping. These are the primary entry
  +points to Spring's core container for all common purposes: loading of configuration
  +files, triggering a classpath scan, programmatically registering bean definitions
  +and annotated classes, and as of 5.0 also registering functional bean definitions.
  +
  +Because an `ApplicationContext` includes all functionality of a `BeanFactory`, it is
  +generally recommended over a plain `BeanFactory`, except for a scenarios where full
  +control over bean processing is needed. Within an `ApplicationContext` such as the
  +`GenericApplicationContext` implementation, several kinds of beans will be detected
  +by convention (i.e. by bean name or by bean type), in particular post-processors,
  +whereas a plain `DefaultListableBeanFactory` is agnostic about any special beans.
  +
  +For many extended container features such as annotation processing and AOP proxying,
  +the <<beans-factory-extension-bpp,`BeanPostProcessor` extension point>> is essential.
  +If you use only a plain `DefaultListableBeanFactory`, such post-processors will not
  +get detected and activated by default. This situation could be confusing because
  +nothing is actually wrong with your bean configuration; it is rather the container
  +which needs to be fully bootstrapped through additional setup in such a scenario.
   
   The following table lists features provided by the `BeanFactory` and
   `ApplicationContext` interfaces and implementations.
  
positive.code: [[context-introduction-ctx-vs-beanfactory-feature-matrix]]
  .Feature Matrix
  |===
  | Feature| `BeanFactory`| `ApplicationContext`
  
  | Bean instantiation/wiring
  | Yes
  | Yes
  
  | Automatic `BeanPostProcessor` registration
  | No
  | Yes
  
negative.code: 	// populate the factory with bean definitions
  
  	// now register any needed BeanPostProcessor instances
  	factory.addBeanPostProcessor(new AutowiredAnnotationBeanPostProcessor());
  	factory.addBeanPostProcessor(new MyBeanPostProcessor());
  
  	// now start using the factory
  ----
  
  To apply a `BeanFactoryPostProcessor` to a plain `DefaultListableBeanFactory`,
  you need to call its `postProcessBeanFactory` method:
  
  [source,java,indent=0]
  [subs="verbatim,quotes"]
  