[weld-dev] Decorator question

Sat Dec 5 01:53:16 EST 2009

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ı!  http://yahoo.com.tr
İnternet üzerindeki en iyi içeriği Yahoo! Türkiye sizlere sunuyor!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20091204/71e532bc/attachment-0001.html 