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

stephen caruso stephen.caruso at oracle.com
Mon Oct 21 12:35:07 EDT 2013

On 10/21/13 8:15 AM, Pete Muir wrote:
> 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?
This is something I'll keep a watch on.  There would likely be some 
commitments needed that I currently cannot sign up for.


Stephen Caruso
Sr. S/W Manager
Java EE Compatibility
Oracle Corp.
Stephen.Caruso at oracle.com

More information about the cdi-dev mailing list