[weld-dev] Delegate attributes with concrete type

[Marius Bogoevici]

Gavin King wrote:
> Pete, Marius, what do we actually do with respect to this in the RI and TCK?
>   
Gavin,

What we do there is close to (1), with the difference that a new proxy 
is created for every delegate injection point in a decorator chain (but 
this might be refactored a bit in 1.0.1, at the same time as fixing 
WELD-291). Concrete types can be delegates, but at least in principle, 
we should observe the rule which says that only methods defined on 
decorated types (which are a subset of the types of the delegate type)  
are to be actually decorated (i.e. if the decorator had a method with 
the same signature as a method defined on the target class *but* the 
combined set of decorated types of the class do not declare the method, 
it won't decorate squat).

That is one aspect of the problem. In general, it seems like making the 
specification more restrictive (in the sense that delegate injection 
points *must* be interfaces) would eliminate a source of confusion.

And now I'll sidetrack :).

Since this has been brought into discussion, I see a potentially 
different course of action. It is probably too late in the process for 
this kind of input, but it might be useful for *future versions* of the 
specification. The current discussion is revolving around implementing 
interfaces as the only way of declaring the decorated types for a 
decorator and started with Mark's observation that you can't decorate a 
concrete type per se, which is currently true (you can decorate an 
interface which is implemented by said concrete type, but that's a 
different story). I am wondering the need for a Decorator to actually 
implement an interface it decorates is the only way to go? Could 
something like the following be considered for a future version 
(stressing that again) of the specification?

@Decorator(types={AnInterface.class, AnotherInterface.class})
public class SomeDecorator
{ ... }

This could have the advantage that you could specify *concrete types* as 
decorated types without having to extend them (and thus bring the whole 
extra baggage of behaviour inheritance into the decorator). This could 
be useful for cases when the beans do not implement interfaces (whether 
it is a good practice to program against interfaces or not, it's not the 
point here). Of course, this also brings up the whole host of problems 
created by the need to have derived proxies for the concrete classes 
(which may or may not have no-arg constructors), etc. I am not sure if 
the latter was the main reason for which you avoided concrete class 
decoration, but if the option is still on the table, perhaps the above 
could be a nice way to separate inheritance from decoration?

Cheers,
Marius



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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20091206/3da7f986/attachment.html