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

[Bill Shannon]

Pete Muir wrote on 10/20/2013 04:04 PM:
> 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?

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?