<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Are few thoughts:<br>
<br>
a) You can still have (2), if AnotherBeanClass implements an interface
AnInterface. It's just that the set of decorated methods is restricted
to the ones defined in the interface.<br>
<br>
b) I can see a few of wrinkles in (2), when combining @Decorator with
inheritance from the delegate type (even in case a) ), as a @Decorator
subclass will inherit methods implemented in the parent (which is also
the delegate), which can mean that a method b() inherited from the
parent class (but not overridden) will be automatically used to
decorate method b() on the delegate ...<br>
<br>
c) Not to be presumptuous, but wouldn't @Alternative be better suited
to such use cases as (2) ?<br>
<br>
<br>
Gavin King wrote:
<blockquote
 cite="mid:db199550912031501i51875739x420c4c780b329f4@mail.gmail.com"
 type="cite">
  <pre wrap="">(2) is not supported in the spec. Decorators can't decorate concrete types.

On Thu, Dec 3, 2009 at 4:42 PM, Mark Struberg <a class="moz-txt-link-rfc2396E" href="mailto:struberg@yahoo.de">&lt;struberg@yahoo.de&gt;</a> wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Hi folks!

I'm a bit unsure about the interpretation of the section 8 Decorators in the spec.

There is a sentence which really confuses me:
"The set of decorated types of a decorator includes all bean types of the managed bean which are Java interfaces..."

I always thought about 2 use cases:

1.)
@Decorator
public class MyDec1 implements AnInterface {
&nbsp;@Inject @Delegate AnInterface1 theRealThing;
&nbsp;...
}

which will decorate all beans which implement the AnInterface.

2.)
@Decorator
public class MyDec2 extends AnotherBeanClass {
&nbsp;@Inject @Delegate AnotherBeanClass theRealThing;
&nbsp;...
}

which will decorate all beans which are of Type (+subclasses) of AnotherBeanClass.

This thoughts are basically backed by a few other paragraphs in the spec and also by the TCK (org.jboss.jsr299.tck.tests.lookup.injectionpoint.CatDecorator).

But for 2) the AnotherBeanClass doesn't need to implement any Interface at all (at least from the practical point of view).


txs and LieGrue,
strub

__________________________________________________
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verf&uuml;gt &uuml;ber einen herausragenden Schutz gegen Massenmails.
<a class="moz-txt-link-freetext" href="http://mail.yahoo.com">http://mail.yahoo.com</a>

_______________________________________________
weld-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/weld-dev">https://lists.jboss.org/mailman/listinfo/weld-dev</a>

    </pre>
  </blockquote>
  <pre wrap=""><!---->


  </pre>
</blockquote>
<br>
</body>
</html>