[cdi-dev] EE 7 "component classes supporting injection" and interceptors

Pete Muir pmuir at redhat.com
Sun Oct 20 19:04:27 EDT 2013


Hi Bil,



On 18 Oct 2013, at 14:01, Bill Shannon <bill.shannon at oracle.com> wrote:

> Yes, this is one of those "integration" requirements that would normally be
> tested by the spec that specifies the requirement.  The challenge, of course,
> is what is the correct division of responsibilities for testing.  Only the
> CDI tests should know how to test that injection is working properly in a
> CDI bean.  The other specs effectively say that this class that CDI would
> not otherwise consider a bean must be considered a bean.

In this case, it looks like it's the Java EE spec itself that makes the integration requirement, but I don't think that has a TCK?

> 
> It might be reasonable for the Servlet and WebSocket TCKs to do some simple
> injection testing for these classes.  But if you wanted more complete testing
> of injection for these classes, it would be good if the tests in these other
> TCKs had a way to delegate that testing to the CDI TCK.  This is not really a
> spec issue, but more of a software engineering issue.  I would let the TCK
> groups figure out how best to handle this.  I definitely wouldn't want the
> Servlet or WebSockets TCK to attempt to duplicate all the CDI injection tests.

This is a good idea. What about if the CDI TCK included some sort of (new, simple) embeddable jar, that other TCKs could reuse. With some external config, this could execute the relevant injection tests, but leave the setup to the other TCK (as thats normally the part that CDI doesn't specify). WDYT?

> 
> Pete Muir wrote on 10/18/13 07:20:
>> Bill/Linda,
>> 
>> Question about whose responsibility it is to test injections into Java EE components.
>> 
>> Pete
>> 
>> On 18 Oct 2013, at 13:49, Martin Kouba <mkouba at redhat.com> wrote:
>> 
>>> Dne 17.10.2013 15:07, Pete Muir napsal(a):
>>>> 
>>>> On 17 Oct 2013, at 12:06, Martin Kouba <mkouba at redhat.com> wrote:
>>>> 
>>>>> Hi all,
>>>>> 
>>>>> today when I walked through EE 7 umbrella spec I found some parts which
>>>>> indicate that all "component classes supporting injection" (servlets,
>>>>> JSP tag handlers, ...) must also support
>>>>> interceptors (if CDI is enabled).
>>>>> 
>>>>> EE.5.24 Support for Dependency Injection
>>>>> "Therefore, to make injection support more uniform across all Java EE
>>>>> component types, Java EE containers are required to support field,
>>>>> method, and constructor injection using the javax.inject.Inject
>>>>> annotation into all component classes listed in Table EE.5-1 as having
>>>>> the “Standard” level of injection support, as well as the use of
>>>>> interceptors for these classes."
>>>>> 
>>>>> EE.5.2.5 Annotations and Injection
>>>>> "The component classes listed in Table EE.5-1 with support level
>>>>> “Standard” all support Java EE resource injection, as well as
>>>>> PostConstruct and PreDestroy callbacks. In addition, if CDI is
>>>>> enabled—which it is by default—these classes also support CDI injection,
>>>>> as described in Section EE.5.24, “Support for Dependency Injection”, and
>>>>> the use of interceptors."
>>>>> 
>>>>> Is my interpretation correct or am I missing something? Actually I doubt
>>>>> it works correctly on EE 7 containers out there.
>>>> 
>>>> I believe you are correct. I think I also asked Bill and Linda about whose responsibility it was to test this, and it wasn't ours (though we could test it if we wanted).
>>> 
>>> I think individual specs which mention this requirement (e.g. Servlet
>>> and WebSocket) should test it (I guess there's no "EE umbrella
>>> integration TCK").
>>> 
>>>> 
>>>> Do you want me to follow up with them?
>>> 
>>> Please do. Thanks! :-)
>>> 
>>>> 
>>>>> 
>>>>> M
>>>>> 
>>>>> -- 
>>>>> Martin Kouba
>>>>> JBoss Quality Assurance Engineer
>>>>> CDI TCK lead
>>>>> Red Hat, Czech Republic
>>>>> _______________________________________________
>>>>> cdi-dev mailing list
>>>>> cdi-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>> 
>>> 
>> 
>> 
> 




More information about the cdi-dev mailing list