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 {  @Inject @Delegate AnInterface1 theRealThing;  ... } which will decorate all beans which implement the AnInterface. 2.) @Decorator public class MyDec2 extends AnotherBeanClass {  @Inject @Delegate AnotherBeanClass theRealThing;  ... } 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ügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev

(2) is not supported in the spec. Decorators can't decorate concrete types. On Thu, Dec 3, 2009 at 4:42 PM, Mark Struberg <struberg(a)yahoo.de&gt; wrote: > 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 { > @Inject @Delegate AnInterface1 theRealThing; > ... > } > > which will decorate all beans which implement the AnInterface. > > 2.) > @Decorator > public class MyDec2 extends AnotherBeanClass { > @Inject @Delegate AnotherBeanClass theRealThing; > ... > } > > 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ügt über einen herausragenden Schutz gegen Massenmails. > http://mail.yahoo.com > > _______________________________________________ > weld-dev mailing list > weld-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev > >

Von: Gavin King <gavin.king(a)gmail.com&gt; Betreff: Re: [weld-dev] Decorator question An: "Marius Bogoevici" <mariusb(a)redhat.com&gt; CC: "Mark Struberg" <struberg(a)yahoo.de&gt;, weld-dev(a)lists.jboss.org Datum: Freitag, 4. Dezember 2009, 1:56 On Thu, Dec 3, 2009 at 6:44 PM, Marius Bogoevici <mariusb(a)redhat.com&gt; wrote: > 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. Actually, yes, that's true. I should have said that.

Von: Gavin King <gavin.king(a)gmail.com&gt; Betreff: Re: [weld-dev] Decorator question An: "Mark Struberg" <struberg(a)yahoo.de&gt; CC: "Marius Bogoevici" <mariusb(a)redhat.com&gt;, weld-dev(a)lists.jboss.org Datum: Freitag, 4. Dezember 2009, 17:51 Look, I just don't see the usecase for what you're proposing. If you're trying to extend a concrete class, override some of its methods, and delegate some methods back to the superclass, just make your subclass an @Alternative and call super. I simply don't see the usecase for having a whole stack of these things. I don't think anyone needs this. On Fri, Dec 4, 2009 at 2:21 AM, Mark Struberg <struberg(a)yahoo.de&gt; wrote: > But if (2) is allowed, then the restriction on the Interfaces is pretty restrictive. I cannot see any additional benefit we gain from this restriction and we have to delegate all not-overridden methods via a proxy anyway. > Can you please give me a hint why this is necessary? > > txs and lieGrue, > strub > > > --- Gavin King <gavin.king(a)gmail.com&gt; schrieb am Fr, 4.12.2009: > >> Von: Gavin King <gavin.king(a)gmail.com&gt; >> Betreff: Re: [weld-dev] Decorator question >> An: "Marius Bogoevici" <mariusb(a)redhat.com&gt; >> CC: "Mark Struberg" <struberg(a)yahoo.de&gt;, weld-dev(a)lists.jboss.org >> Datum: Freitag, 4. Dezember 2009, 1:56 >> On Thu, Dec 3, 2009 at 6:44 PM, >> Marius Bogoevici <mariusb(a)redhat.com&gt; >> wrote: >> >> > 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. >> >> Actually, yes, that's true. I should have said that. > > __________________________________________________ > Do You Yahoo!? > Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. > http://mail.yahoo.com > -- Gavin King gavin.king(a)gmail.com http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org

Then I guess I don't understand exactly what it is that you want here... On Fri, Dec 4, 2009 at 6:20 PM, Mark Struberg <struberg(a)yahoo.de&gt; wrote: > Gavin, > > my main concern is to pass the TCK. > > Beside that, I really don't like to propose new use cases (even if there is one: with @Alternative, you'd need to subclass every class down the type hierarchy yourself, with @Decorator 'extends', you'd be able to decorate the baseclass and that would be applied to all subclasses automagically). > > Maybe the TCK folks can look at the CatDecorator, and add a bit more Decorator tests, so we have a set of facts we can both rely on? txs! > > LieGrue, > strub > > --- Gavin King <gavin.king(a)gmail.com&gt; schrieb am Fr, 4.12.2009: > >> Von: Gavin King <gavin.king(a)gmail.com&gt; >> Betreff: Re: [weld-dev] Decorator question >> An: "Mark Struberg" <struberg(a)yahoo.de&gt; >> CC: "Marius Bogoevici" <mariusb(a)redhat.com&gt;, weld-dev(a)lists.jboss.org >> Datum: Freitag, 4. Dezember 2009, 17:51 >> Look, I just don't see the usecase >> for what you're proposing. >> >> If you're trying to extend a concrete class, override some >> of its >> methods, and delegate some methods back to the superclass, >> just make >> your subclass an @Alternative and call super. >> >> I simply don't see the usecase for having a whole stack of >> these >> things. I don't think anyone needs this. >> >> On Fri, Dec 4, 2009 at 2:21 AM, Mark Struberg <struberg(a)yahoo.de&gt; >> wrote: >> > But if (2) is allowed, then the restriction on the >> Interfaces is pretty restrictive. I cannot see any >> additional benefit we gain from this restriction and we have >> to delegate all not-overridden methods via a proxy anyway. >> > Can you please give me a hint why this is necessary? >> > >> > txs and lieGrue, >> > strub >> > >> > >> > --- Gavin King <gavin.king(a)gmail.com&gt; >> schrieb am Fr, 4.12.2009: >> > >> >> Von: Gavin King <gavin.king(a)gmail.com&gt; >> >> Betreff: Re: [weld-dev] Decorator question >> >> An: "Marius Bogoevici" <mariusb(a)redhat.com&gt; >> >> CC: "Mark Struberg" <struberg(a)yahoo.de&gt;, >> weld-dev(a)lists.jboss.org >> >> Datum: Freitag, 4. Dezember 2009, 1:56 >> >> On Thu, Dec 3, 2009 at 6:44 PM, >> >> Marius Bogoevici <mariusb(a)redhat.com&gt; >> >> wrote: >> >> >> >> > 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. >> >> >> >> Actually, yes, that's true. I should have said >> that. >> > >> > __________________________________________________ >> > Do You Yahoo!? >> > Sie sind Spam leid? Yahoo! Mail verfügt über einen >> herausragenden Schutz gegen Massenmails. >> > http://mail.yahoo.com >> > >> >> >> >> -- >> Gavin King >> gavin.king(a)gmail.com >> http://in.relation.to/Bloggers/Gavin >> http://hibernate.org >> http://seamframework.org >> > > __________________________________________________ > Do You Yahoo!? > Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. > http://mail.yahoo.com > -- Gavin King gavin.king(a)gmail.com http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org

Von: Gurkan Erdogdu <gurkanerdogdu(a)yahoo.com&gt; Betreff: Re: [weld-dev] Decorator question An: weld-dev(a)lists.jboss.org Datum: Samstag, 5. Dezember 2009, 7:53 Hi; What I understand from the spec is that : 1* Decorated types of the decorator must be an interface     Examples :     a) Just implement interface      @Decorator public class X implements Y      Decorated types of X : {Y}         b)  Abstract implementation       @Decorator abstract class X implement Y       interface Y extends YY       Decorated types of X : {Y,YY}      c)Extends class Y that is not decorator that implement another interface YY       @Decorator public class X extends Y implement Z;        public class Y implement YY        interface Z extends ZZ        Decorated types of X : {YY, Z, ZZ} 2* Delegate type of the decorator must be "implement" or "extends" decorated types     1.a ) Proxy that implements {Y}     1.b ) Proxy that implements  {Y} and {YY}     1.c)  Proxy that implement {YY, Z, ZZ} Moreover, delegate proxy is used for calling chaining of decorators. Lets say that 3 decorator instance @Decorator public class A implements X {@Delegate X x public void checkout(){ ... x.checkout()}} @Decorator public class B implements X {@Delegate X x public void checkout(){... x.checkout()}}  @Decorator public class C implements X {@Delegate X x public void checkout(){..  x. checkout()}} Then, managed beans with API type containing X have a 3 decorators if these decorators are enabled. So, whenever a call is made to the managed bean instance(decorate method call) first decorator in the chain is called by the container. Lets say that first decorator is A, so A's "checkout" method is called and delegate proxy instance is injected into its injection point by the container. A{        @Delegate X x; --> Proxy injected by the container      public void checkout(){          ......          x.checkout() --> Means that calls another decorator in the chain if exist, otherwise call actual bean instance    } } In A, delegate proxy is used for calling another decorator in the chain if it exists.  For above example, B#checkout() is called, etc... If there is no call to the delegate proxy object's method(x.checkout()), then actual bean instance is called with skipping other decorators in the chain. Is this correct? Thanks; --Gurkan From: Gavin King <gavin.king(a)gmail.com&gt; To: Mark Struberg <struberg(a)yahoo.de&gt; Cc: weld-dev(a)lists.jboss.org Sent: Sat, December 5, 2009 6:21:47 AM Subject: Re: [weld-dev] Decorator question Oh, now I understand. Yes, Cat/CatDecorator look wrong to me. Cat should be an interface, with a CatImpl. On Fri, Dec 4, 2009 at 8:42 PM, Gavin King <gavin.king(a)gmail.com&gt; wrote: > Then I guess I don't understand exactly what it is that you want here... > > On Fri, Dec 4, 2009 at 6:20 PM, Mark Struberg <struberg(a)yahoo.de&gt; wrote: >> Gavin, >> >> my main concern is to pass the TCK. >> >> Beside that, I really don't like to propose new use cases (even if there is one: with @Alternative, you'd need to subclass every class down the type hierarchy yourself, with @Decorator 'extends', you'd be able to decorate the baseclass and that would be applied to all subclasses automagically). >> >> Maybe the TCK folks can look at the CatDecorator, and add a bit more Decorator tests, so we have a set of facts we can both rely on? txs! >> >> LieGrue, >> strub >> >> --- Gavin King <gavin.king(a)gmail.com&gt; schrieb am Fr, 4.12.2009: >> >>> Von: Gavin King <gavin.king(a)gmail.com&gt; >>> Betreff: Re: [weld-dev] Decorator question >>> An: "Mark Struberg" <struberg(a)yahoo.de&gt; >>> CC: "Marius Bogoevici" <mariusb(a)redhat.com&gt;, weld-dev(a)lists.jboss.org >>> Datum: Freitag, 4. Dezember 2009, 17:51 >>> Look, I just don't see the usecase >>> for what you're proposing. >>> >>> If you're trying to extend a concrete class, override some >>> of its >>> methods, and delegate some methods back to the superclass, >>> just make >>> your subclass an @Alternative and call super. >>> >>> I simply don't see the usecase for having a whole stack of >>> these >>> things. I don't think anyone needs this. >>> >>> On Fri, Dec 4, 2009 at 2:21 AM, Mark Struberg <struberg(a)yahoo.de&gt; >>> wrote: >>> > But if (2) is allowed, then the restriction on the >>> Interfaces is pretty restrictive. I cannot see any >>> additional benefit we gain from this restriction and we have >>> to delegate all not-overridden methods via a proxy anyway. >>> > Can you please give me a hint why this is necessary? >>> > >>> > txs and lieGrue, >>> > strub >>> > >>> > >>> > --- Gavin King <gavin.king(a)gmail.com&gt; >>> schrieb am Fr, 4.12.2009: >>> > >>> >> Von: Gavin King <gavin.king(a)gmail.com&gt; >>> >> Betreff: Re: [weld-dev] Decorator question >>> >> An: "Marius Bogoevici" <mariusb(a)redhat.com&gt; >>> >> CC: "Mark Struberg" <struberg(a)yahoo.de&gt;, >>> weld-dev(a)lists.jboss.org >>> >> Datum: Freitag, 4. Dezember 2009, 1:56 >>> >> On Thu, Dec 3, 2009 at 6:44 PM, >>> >> Marius Bogoevici <mariusb(a)redhat.com&gt; >>> >> wrote: >>> >> >>> >> > 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. >>> >> >>> >> Actually, yes, that's true. I should have said >>> that. >>> > >>> > __________________________________________________ >>> > Do You Yahoo!? >>> > Sie sind Spam leid? Yahoo! Mail verfügt über einen >>> herausragenden Schutz gegen Massenmails. >>> > http://mail.yahoo.com >>> > >>> >>> >>> >>> -- >>> Gavin King >>> gavin.king(a)gmail.com >>> http://in.relation.to/Bloggers/Gavin >>> http://hibernate.org >>> http://seamframework.org >>> >> >> __________________________________________________ >> Do You Yahoo!? >> Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. >> http://mail.yahoo.com >> > > > > -- > Gavin King > gavin.king(a)gmail.com > http://in.relation.to/Bloggers/Gavin > http://hibernate.org > http://seamframework.org > -- 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 Yahoo! Türkiye açıldı! Haber, Ekonomi, Videolar, Oyunlar hepsi Yahoo! Türkiye'de! www.yahoo.com.tr -----Integrierter Anhang folgt----- _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev

Von: Gavin King <gavin.king(a)gmail.com&gt; Betreff: Re: [weld-dev] Decorator question An: "Mark Struberg" <struberg(a)yahoo.de&gt; CC: "Marius Bogoevici" <mariusb(a)redhat.com&gt;, weld-dev(a)lists.jboss.org Datum: Samstag, 5. Dezember 2009, 5:21 Oh, now I understand. Yes, Cat/CatDecorator look wrong to me. Cat should be an interface, with a CatImpl. On Fri, Dec 4, 2009 at 8:42 PM, Gavin King <gavin.king(a)gmail.com&gt; wrote: > Then I guess I don't understand exactly what it is that you want here... > > On Fri, Dec 4, 2009 at 6:20 PM, Mark Struberg <struberg(a)yahoo.de&gt; wrote: >> Gavin, >> >> my main concern is to pass the TCK. >> >> Beside that, I really don't like to propose new use cases (even if there is one: with @Alternative, you'd need to subclass every class down the type hierarchy yourself, with @Decorator 'extends', you'd be able to decorate the baseclass and that would be applied to all subclasses automagically). >> >> Maybe the TCK folks can look at the CatDecorator, and add a bit more Decorator tests, so we have a set of facts we can both rely on? txs! >> >> LieGrue, >> strub >> >> --- Gavin King <gavin.king(a)gmail.com&gt; schrieb am Fr, 4.12.2009: >> >>> Von: Gavin King <gavin.king(a)gmail.com&gt; >>> Betreff: Re: [weld-dev] Decorator question >>> An: "Mark Struberg" <struberg(a)yahoo.de&gt; >>> CC: "Marius Bogoevici" <mariusb(a)redhat.com&gt;, weld-dev(a)lists.jboss.org >>> Datum: Freitag, 4. Dezember 2009, 17:51 >>> Look, I just don't see the usecase >>> for what you're proposing. >>> >>> If you're trying to extend a concrete class, override some >>> of its >>> methods, and delegate some methods back to the superclass, >>> just make >>> your subclass an @Alternative and call super. >>> >>> I simply don't see the usecase for having a whole stack of >>> these >>> things. I don't think anyone needs this. >>> >>> On Fri, Dec 4, 2009 at 2:21 AM, Mark Struberg <struberg(a)yahoo.de&gt; >>> wrote: >>> > But if (2) is allowed, then the restriction on the >>> Interfaces is pretty restrictive. I cannot see any >>> additional benefit we gain from this restriction and we have >>> to delegate all not-overridden methods via a proxy anyway. >>> > Can you please give me a hint why this is necessary? >>> > >>> > txs and lieGrue, >>> > strub >>> > >>> > >>> > --- Gavin King <gavin.king(a)gmail.com&gt; >>> schrieb am Fr, 4.12.2009: >>> > >>> >> Von: Gavin King <gavin.king(a)gmail.com&gt; >>> >> Betreff: Re: [weld-dev] Decorator question >>> >> An: "Marius Bogoevici" <mariusb(a)redhat.com&gt; >>> >> CC: "Mark Struberg" <struberg(a)yahoo.de&gt;, >>> weld-dev(a)lists.jboss.org >>> >> Datum: Freitag, 4. Dezember 2009, 1:56 >>> >> On Thu, Dec 3, 2009 at 6:44 PM, >>> >> Marius Bogoevici <mariusb(a)redhat.com&gt; >>> >> wrote: >>> >> >>> >> > 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. >>> >> >>> >> Actually, yes, that's true. I should have said >>> that. >>> > >>> > __________________________________________________ >>> > Do You Yahoo!? >>> > Sie sind Spam leid? Yahoo! Mail verfügt über einen >>> herausragenden Schutz gegen Massenmails. >>> > http://mail.yahoo.com >>> > >>> >>> >>> >>> -- >>> Gavin King >>> gavin.king(a)gmail.com >>> http://in.relation.to/Bloggers/Gavin >>> http://hibernate.org >>> http://seamframework.org >>> >> >> __________________________________________________ >> Do You Yahoo!? >> Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. >> http://mail.yahoo.com >> > > > > -- > Gavin King > gavin.king(a)gmail.com > http://in.relation.to/Bloggers/Gavin > http://hibernate.org > http://seamframework.org > -- Gavin King gavin.king(a)gmail.com http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org