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.

M -- Martin Kouba JBoss Quality Assurance Engineer CDI TCK lead Red Hat, Czech Republic _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev

Dne 17.10.2013 15:07, Pete Muir napsal(a): > > On 17 Oct 2013, at 12:06, Martin Kouba <mkouba(a)redhat.com&gt; 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >

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.

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.

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(a)redhat.com&gt; wrote: > >> Dne 17.10.2013 15:07, Pete Muir napsal(a): >>> >>> On 17 Oct 2013, at 12:06, Martin Kouba <mkouba(a)redhat.com&gt; 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(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >> > >

Pete Muir wrote on 10/20/2013 04:04 PM: > Hi Bil, > > > > On 18 Oct 2013, at 14:01, Bill Shannon <bill.shannon(a)oracle.com&gt; 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? Yes, it does, it's the "CTS". It collects together all the other TCKs plus integration tests. >> 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? Sounds reasonable. Talk to the other TCK owners and figure out what's best.

Steve, Kyle, any comments?