We support taking this approach :-)
On 4 Dec 2012, at 22:10, Linda DeMichiel wrote:
>
> 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 http://www.seamframework.org/Documentation/HowDoIDoNoncontextualInjectionForAThirdpartyFramework).
>
> 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
> CDI SPI.
>
> 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
> CDI SPIs:
>
> 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 https://issues.jboss.org/browse/WELD-1049.
> 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.
>
>
> thanks,
>
> -Linda
>
>
>
>
>
>