Hrm, I just noticed something that I had not realized. Prior to May 14, the CDI spec said that the "delegate attribute" had to have an interface type. On May 14, I refactored this section to make "delegate injection points" just a special kind of injection point. And I removed - perhaps intentionally, but much more likely unintentionally, since I did not mention it to the EG in my emails - the restriction that the type of the delegate injection point had to be an interface type. At some later stage I guess I got used to this restriction not being there, and it just slipped through the cracks without me ever really thinking through the consequences. The problem with this is that if we have a delegate with a concrete type, we have two possible implementations for the delegate attribute: (1) inject a proxy, derived from the concrete class, or (2) inject the actual intercepted instance and keep track of the current decorator in a threadlocal. When I originally designed this stuff, I had hoped to avoid both these options. I'm a bit upset that I screwed up here, and that we did not discover it until now. Now, this is not the end of the world, the spec is still implementable, and this only affects you if you actually *do* have a decorator with a concrete delegate injection point type. Which is, in fact, a useful feature. But I'm wondering if we should "challenge" the spec? It's not too late to fix this, I think. Roberto, what would be the process if we decided to do this? The language that went missing was: "The declared type of the delegate attribute must be a Java interface type [snip]. If the declared type of a delegate attribute is not a Java interface type [snip], the container automatically detects the problem and treats it as a definition error [snip]."