anchor.diff:  The more centric meta-data created by CDI container is the collection of `Bean<T>` discovered during deployment.
   These metadata are the real applications _beans_ and in basic CDI usage you'll never use them.
   
  -So don't mix _beans_ and the _beans instances_ you request to the container when adding an injection point in your code.
  +So don't mix _beans_ and the _contextual instances_ (instances of the bean for a given context) you request to the container when adding an injection point in your code.
   
   === The content of `Bean<T>` interface
   
   The `Bean` interface has two main functions:
   
  -* Providing a "recipe" to create and destroy bean instances (methods from `Contextual<T>`)
  +* Providing a "recipe" to create and destroy contextual instances (methods from `Contextual<T>`)
   * Storing bean metadata obtained from bean definition (methods from `BeanAttributes<T>`)
   
   
  
positive.code: 
  That's not correct and it's important to understand the exact mechanism behind this injection point definition.
  
  === Bean vs Bean instances
  
  One of the specific feature in CDI is the fact that all components (qualifiers, beans, producers, etc..) are discovered at deployment time.
  
  
negative.code: Yet, for a lot of user, this concept stays fuzzy and requires experiment to achieve an expected result.
  In this article I'll try to clarify most of bean related concepts and detail the hidden mechanism behind bean definition and injection.
  
  == Bean, contextual instance and typesafe resolution
  
  When most CDI users write
  
  