[jsr-314-open-mirror] [jsr-314-open] CDI constructor integration

[Stephen Kenna]

Sorry for the delayed response.  This one fell off my radar...

 >From the EE6 spec, Section EE.5.20 states: 
>> 
>>     Per the CDI specification, dependency injection is supported on 
managed 
>> beans. There are currently three ways for a class to become a managed 
bean: 
...
>>  3. Satisfying the conditions in Section 3.1 of the CDI specification. 
>>     Classes that satisfy at least one of these conditions will be 
eligible for full 
>>     dependency injection support, as described in CDI. 

Section 3.1 of the 299 spec says:
3.1.1. Which Java classes are managed beans?
A top-level Java class is a managed bean if it is defined to be a managed 
bean by any other Java EE specification, or if it
meets all of the following conditions:
• It is not a non-static inner class.
• It is a concrete class, or is annotated @Decorator.
• It is not annotated with an EJB component-defining annotation or 
declared as an EJB bean class in ejb-jar.xml.
• It does not implement javax.enterprise.inject.spi.Extension.
• It has an appropriate constructor—either:
• the class has a constructor with no parameters, or
• the class declares a constructor annotated @Inject.
All Java classes that meet these conditions are managed beans and thus no 
special declaration is required to define a managed
bean.

>>If you think about it, this makes sense. If you are in a CDI enabled 
bean archive, then why would you be using JSF managed beans. If you aren't 
in a CDI enabled bean archive, ctor injection is certainly >>not required.
I believe that you could be taking a current archive that contains JSF 
managed beans, turn it into a BDA, and then want to use ctor injection. 
Having to remove JSF annotations to get this to work seems unwarranted, 
and a moot point if the language in Section 3.1 of CDI says we should be 
supporting it. 

I am writing to the CDI EG to get further clarification. I actually agree 
with your interpretation, but would still like to get it strongly worded 
in the specs.  The loose definition of managed beans between all the specs 
is very confusing. 

Regards,
Stephen


stephen kenna                                           ibm websphere 
architecture & development



On 24 Jun 2010, at 07:46, Roger Kitain wrote:

>> Hi Stephan - 
>> 
>> We have an open issue in Mojarra to support @Inject into JSF Managed 
Beans.

>I believe this is for field injection only.

> 
> Thanks, Roger.
> 
> On 6/24/10 10:42 AM, Stephen Kenna wrote:
>> We have internally been discussing @Inject into @ManagedBeans (should 
be the same for JSF Managed beans defined in the faces-config.xml). 
>> 
>> Originally we were trying to figure out if JSF managed beans should 
support constructor injection if they were inside a BDA (in other words, 
if JSF should defer to CDI for creation). 
>> 
>> We did some testing on Glassfish, and not only did constructor 
injection not occur, but field injection did not occur either.  (Field 
injection is working on JBoss) 
>> 
>> My reading of JSR-299 & the EE6 spec differs from this. 
>> 
>> >From JSR299 Section 1.2.1: 
>> In the Java EE 6 environment, all component classes supporting 
injection, as defined by the Java EE 6 platform specifica- 
>> tion, may inject beans via the dependency injection service. 
>> 
>> Or JSR299 Section 3.8: 
>> An injected field is a non-static, non-final field of a bean class, or 
of any Java EE component class supporting injection. 
>> 
>> >From the EE6 spec, Section EE.5.20 states: 
>> 
>>     Per the CDI specification, dependency injection is supported on 
managed 
>> beans. There are currently three ways for a class to become a managed 
bean: 
>>  1. Being an EJB session bean component. 
>>  2. Being annotated with the @ManagedBean annotation. 
>>  3. Satisfying the conditions in Section 3.1 of the CDI specification. 
>>     Classes that satisfy at least one of these conditions will be 
eligible for full 
>> dependency injection support, as described in CDI. 
>> 
>> and 
>> 
>>      Clearly, in the absence of any additional annotations, most 
component classes 
>> listed in Table EE.5-1 will not be managed beans. So as to make 
injection support 
>> more uniform across all component types, Java EE containers are 
required to 
>> support field or method injection (but not constructor injection) using 

>> @javax.inject.Inject on all component classes listed in Table EE.5-1 
when the 
>> containing archive is a bean archive. 
>> 
>> Our interpretation of the above is that we definitely need to support 
field injection of @Inject into @ManagedBean beans,

>Yes, this is definitely clear :-)

>> and we also need to support constructor injection 

>I'm pretty you don't. The @ManagedBean which causes the JSF managed bean 
container to get involved is *different* to the @ManagedBean which the EE 
spec indicates should support >(javax.faces.bean.ManagedBean vs 
javax.annotation.Managed - and yes, IMO this is a crazy divergence, and we 
did argue against it). Using this logic, there is *no way* for a managed 
bean which lives in the >JSF managed bean container to become a managed 
bean as defined by EE.5.20, and thus support ctor injection. So, JSF 
managed beans are just required to support field injection.

>This is what we check in the CDI TCK.

>If you think about it, this makes sense. If you are in a CDI enabled bean 
archive, then why would you be using JSF managed beans. If you aren't in a 
CDI enabled bean archive, ctor injection is certainly >not required.

>HTH

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20100730/a798100e/attachment-0002.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 4542 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20100730/a798100e/attachment-0002.gif