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