anchor.diff:  [source,java,indent=0]
   [subs="verbatim,quotes"]
   ----
  -	public class EntityCreatedEvent<T>
  -			extends ApplicationEvent implements ResolvableTypeProvider {
  +	public class EntityCreatedEvent<T> extends ApplicationEvent implements ResolvableTypeProvider {
   
   		public EntityCreatedEvent(T entity) {
   			super(entity);
  
positive.code: 	// populate the factory with bean definitions
  
  	// now register any needed BeanPostProcessor instances
  	MyBeanPostProcessor postProcessor = new MyBeanPostProcessor();
  	factory.addBeanPostProcessor(postProcessor);
  
  	// now start using the factory
  ----
  
  To explicitly register a `BeanFactoryPostProcessor` when using a `BeanFactory`
  implementation, you must write code like this:
  
  [source,java,indent=0]
  [subs="verbatim,quotes"]
  
negative.code: 	cfg.postProcessBeanFactory(factory);
  ----
  
  In both cases, the explicit registration steps are inconvenient, which is
  why the various `ApplicationContext` variants are preferred over a plain
  `DefaultListableBeanFactory` in Spring-backed applications, especially when
  relying on ``BeanFactoryPostProcessor``s and ``BeanPostProcessor``s for extended
  container functionality in a typical enterprise setup.
  
  [NOTE]
  ====
  An `AnnotationConfigApplicationContext` has all common annotation post-processors
  registered out of the box and may bring in additional processors underneath the
  covers through configuration annotations such as `@EnableTransactionManagement`.
  At the abstraction level of Spring's annotation-based configuration model,
  the notion of bean post-processors becomes a mere internal container detail.
  ====
  