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

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(a)gmail.com&gt; > 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(a)gmail.com >> http://in.relation.to/Bloggers/Gavin >> http://hibernate.org >> http://seamframework.org >> >> >> >> > > > > > _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev

On Mon, Dec 7, 2009 at 8:15 AM, Pete Muir <pmuir(a)redhat.com&gt; wrote: > "The decorator intercepts every method: > > • declared by a decorated type of the decorator > > • that is implemented by the bean class of the decorator." > > I think that needs an "and" or an "or" to make it clear which one it means. I interpreted it as "or", > but apparently it is "and" - I think is why there are some wrong bits in the TCK (at least). It is neither "and" nor "or". It is "that". Get rid of the bullet points, and read it as a single sentence.

File an MR for an errata. Spec version number stays the same. You may want to wait for a few weeks before filing the MR, in case something else pops up.

> What is the time lag between submitting the MR, and it becoming official? > About one week for posting + 30 days MR. Assuming the RI and TCK are already in sync with the errata, the updated spec can get posted right at the end of the MR.