Clean and simple +1 from me!
Thank you!
- M
On 5 December 2012 18:37, Pete Muir <pmuir_at_bleepbleep.org.uk> wrote:
> 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
>>
>>
>>
>>
>>
>>
>
>
>