[javaee-spec users] [jsr342-experts] managed beans, injection, and interceptors

From: Linda DeMichiel <>
Date: Tue, 04 Dec 2012 14:10:38 -0800

We're now at the point where we'd like to resolve the open issues
around improving managed bean alignment in Java EE 7. We'd like
to start with the issue of injection and interceptors.

First, some background information that is relevant here....

We have noticed (and confirmed) that the steps outlined in the Java EE
spec section EE.5.24 for performing injection of non-contextual managed
classes using the CDI SPIs are incorrect.

The correct sequence of steps is the following. These conform to the
recommendations of the Weld project and to what was actually done in the
Java EE 6 reference implementation. (See

I therefore plan to amend section 5.24 as follows to reflect this:

   "....In supporting such injection points, the container must behave
   as if it carried out the following steps, involving the use of the

   1. Obtain a BeanManager instance.

   2. Create an AnnotatedType instance for the component into which
       injection is to occur.

   3. Create an InjectionTarget instance for the annotated type.

   4. Create a CreationalContext, passing in null to the BeanManager
       createCreationalContext method.

   5. Instantiate the component by calling the InjectionTarget produce method.

   6. Inject the component instance by calling the InjectionTarget inject
       method on the instance.

   7. Invoke the PostConstruct callback, if any, by calling the
       InjectionTarget postConstruct method on the instance."

There are a couple of things to note with regard to the use of these

   In step 4, passing null to the createCreationalContext method causes
   the created instances to be non-contextual.

   In step 5, instantiating the objects by means of the produce method
   causes them to be wrapped with interceptors and decorators, and also
   causes the constructor annotated @Inject to be invoked, if it exists.

While this approach has been followed by the RI all along, there was
a bug in the Weld implementation that has caused the interceptors
and decorators to be inactive. See
That bug has since been fixed.

To return to the main point -- which is the pending issue of managed
bean alignment -- the consequence of all of this is that we already
have interceptors and decorators, as well as constructor injection
support for all classes in Table EE.5-1 (with the exception of the
application client classes). While we could of course choose to do
otherwise, we believe that this is the right thing to do, as well as
the most consistent approach. The attached matrix, "matrix 7",
illustrates this.

Finally, in our earlier discussion on managed bean alignment, we had
also raised the issue as to whether these classes should be contextual
objects. Note that as non-contextual objects, they cannot have
producers or observer methods. While it is possible to inject
instances of these classes into other classes, those instances would
not be managed by the container and would be treated as dependent
objects by CDI.

In the future we could consider turning our non-contextual objects
into contextual objects by defining the scope that they belong to.
That might involve defining new scopes that match the lifecycles that
the containers are currently managing themselves.

Please let us know your opinions on these issues.