[weld-dev] Delegate attributes with concrete type

[Gavin King]

Pete, Marius, what do we actually do with respect to this in the RI and TCK?

On Sat, Dec 5, 2009 at 10:36 AM, Gavin King <gavin.king at gmail.com> wrote:
> 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]."
>
> --
> Gavin King
> gavin.king at gmail.com
> http://in.relation.to/Bloggers/Gavin
> http://hibernate.org
> http://seamframework.org
>



-- 
Gavin King
gavin.king at gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org