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@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@gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org