<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Gavin King wrote:
<blockquote
cite="mid:db199550912050738u4ce10c7ei71bcd8d465df009f@mail.gmail.com"
type="cite">
<pre wrap="">Pete, Marius, what do we actually do with respect to this in the RI and TCK?
</pre>
</blockquote>
Gavin,<br>
<br>
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).<br>
<br>
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.<br>
<br>
And now I'll sidetrack :).<br>
<br>
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?<br>
<br>
@Decorator(types={AnInterface.class, AnotherInterface.class})<br>
public class SomeDecorator<br>
{ ... }<br>
<br>
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?<br>
<br>
Cheers,<br>
Marius<br>
<br>
<br>
<br>
<blockquote
cite="mid:db199550912050738u4ce10c7ei71bcd8d465df009f@mail.gmail.com"
type="cite">
<pre wrap="">
On Sat, Dec 5, 2009 at 10:36 AM, Gavin King <a class="moz-txt-link-rfc2396E" href="mailto:gavin.king@gmail.com"><gavin.king@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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
<a class="moz-txt-link-abbreviated" href="mailto:gavin.king@gmail.com">gavin.king@gmail.com</a>
<a class="moz-txt-link-freetext" href="http://in.relation.to/Bloggers/Gavin">http://in.relation.to/Bloggers/Gavin</a>
<a class="moz-txt-link-freetext" href="http://hibernate.org">http://hibernate.org</a>
<a class="moz-txt-link-freetext" href="http://seamframework.org">http://seamframework.org</a>
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>