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

[Pete Muir]

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

> 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.

Martin is going to look at it. It might be something already compiled, or it might be some source code to take and embed.

> 
> Steve, Kyle, any comments?
>