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: 
  
  Another limitation is linked to http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#client_proxies[_client proxies_^].
  In a lot of occasion (interceptor or decorator, passivation, usage of normal scope, possible circularity), the container may need to provide a bean instance wrapped in a proxy.
  For this reason, managed bean classes should be proxyable or the container will raise an exception.
  
  Thus in addition to the above rules the spec also restrictions on managed bean class to support certain services or be in normal scopes.
  
negative.code: 
  * they have qualifiers,
  * they have scope,
  * they can inject other beans: parameters in producer method are injection points that the container will satisfied when it will call the method to produce a contextual instance
  This injection points are still checked at deployment time.
  
  Yet, producers have limitation compared to managed or session bean as *they don't support interceptors or decorators*.
  