[weld-dev] Decorator question

Mark Struberg struberg at yahoo.de
Sat Dec 5 06:12:49 EST 2009 

In fact, that's also what I did understand from reading the spec.

BUT: yesterday I had a long discussion with Pete and it looks like the only real source of the 'decorated type' is in fact the type of the member which is annotated with @Delegate! Because the type of the @Delegated bean exactly defines the beans the decorator will be applied to.

This at least seems to be backed by the weld implementation.

But then another question comes up: why the hell does the decorator itself need to implement an interface at all? The proxy will simply lookup if the decorator has a function with exactly the same signature of the decorated type, and if not will delegate the functions to the @Delegated bean. So defining an interface on the Decorator is nice, but only makes sure that I can use @Override (in Java 1.6) to get the signature right. But technically this restriction is not necessary, isn't?


LieGrue,
strub


--- Gurkan Erdogdu <gurkanerdogdu at yahoo.com> schrieb am Sa, 5.12.2009:

> Von: Gurkan Erdogdu <gurkanerdogdu at yahoo.com>
> Betreff: Re: [weld-dev] Decorator question
> An: weld-dev at 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 at gmail.com>
> To: Mark
> Struberg <struberg at yahoo.de>
> Cc:
> weld-dev at 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 at gmail.com>
> 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 at yahoo.de>
> 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 at gmail.com>
> schrieb am Fr, 4.12.2009:
> >>
> >>> Von: Gavin King <gavin.king at gmail.com>
> >>> Betreff: Re: [weld-dev] Decorator question
> >>> An: "Mark Struberg" <struberg at yahoo.de>
> >>> CC: "Marius Bogoevici" <mariusb at redhat.com>,
> weld-dev at 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 at yahoo.de>
> >>> 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 at gmail.com>
> >>> schrieb am Fr, 4.12.2009:
> >>> >
> >>> >> Von: Gavin King <gavin.king at gmail.com>
> >>> >> Betreff: Re: [weld-dev] Decorator
> question
> >>> >> An: "Marius Bogoevici"
> <mariusb at redhat.com>
> >>> >> CC: "Mark Struberg" <struberg at yahoo.de>,
> >>> weld-dev at lists.jboss.org
> >>> >> Datum: Freitag, 4. Dezember 2009,
> 1:56
> >>> >> On Thu, Dec 3, 2009 at 6:44 PM,
> >>> >> Marius Bogoevici <mariusb at redhat.com>
> >>> >> 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 at 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 at gmail.com
> > http://in.relation.to/Bloggers/Gavin
> > http://hibernate.org
> > http://seamframework.org
> >
> 
> 
> 
> -- 
> Gavin King
> gavin.king at gmail.com
> http://in.relation.to/Bloggers/Gavin
> http://hibernate.org
> http://seamframework.org
> 
> _______________________________________________
> weld-dev mailing list
> weld-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev

__________________________________________________
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. 
http://mail.yahoo.com

More information about the weld-dev mailing list