<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:arial,helvetica,sans-serif;font-size:10pt"><div>Hi;<br><br>What I understand from the spec is that :<br><br>1* Decorated types of the decorator must be an interface<br><br> Examples :<br> a) Just implement interface<br> @Decorator public class X implements Y <br> Decorated types of X : {Y}<br> <br> b) Abstract implementation<br> @Decorator abstract class X implement Y<br> interface Y extends YY<br> Decorated types of X : {Y,YY}<br><br> c)Extends class Y that is not decorator that implement another interface YY<br> @Decorator public class X extends Y implement Z;
<br> public class Y implement YY<br> interface Z extends ZZ<br> Decorated types of X : {YY, Z, ZZ}<br><br>2* Delegate type of the decorator must be "implement" or "extends" decorated types<br> 1.a ) Proxy that implements {Y}<br> 1.b ) Proxy that implements {Y} and {YY}<br> 1.c) Proxy that implement {YY, Z, ZZ}<br><br><br>Moreover, delegate proxy is used for calling chaining of decorators. Lets say that 3 decorator instance<br>@Decorator public class A implements X {@Delegate X x public void checkout(){ ... x.checkout()}} <br>@Decorator public class B implements X {@Delegate X x public void checkout(){... x.checkout()}} <br>@Decorator public class C implements X {@Delegate X x public void checkout(){.. x. checkout()}} <br><br>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. <br><br>A{ <br> @Delegate X x; --> Proxy injected by the container <br> public void checkout(){<br> ......<br> x.checkout() --> Means that calls another decorator in the chain if exist, otherwise call actual bean instance<br> }<br>}<br></div><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt;"><br>In A, delegate proxy is used for calling another decorator in the chain if it exists. For above example, B#checkout() is
called, etc...<br><br>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. <br><br>Is this correct?<br><br>Thanks;<br><br>--Gurkan<br><br><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt;"><font face="Tahoma" size="2"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> Gavin King <gavin.king@gmail.com><br><b><span style="font-weight: bold;">To:</span></b> Mark Struberg <struberg@yahoo.de><br><b><span style="font-weight: bold;">Cc:</span></b> weld-dev@lists.jboss.org<br><b><span style="font-weight: bold;">Sent:</span></b> Sat, December 5, 2009 6:21:47 AM<br><b><span style="font-weight: bold;">Subject:</span></b> Re: [weld-dev] Decorator question<br></font><br>Oh, now I understand. Yes, Cat/CatDecorator look wrong to me. Cat<br>should be an interface, with a CatImpl.<br><br>On Fri, Dec 4, 2009 at 8:42 PM, Gavin
King <<a ymailto="mailto:gavin.king@gmail.com" href="mailto:gavin.king@gmail.com">gavin.king@gmail.com</a>> wrote:<br>> Then I guess I don't understand exactly what it is that you want here...<br>><br>> On Fri, Dec 4, 2009 at 6:20 PM, Mark Struberg <<a ymailto="mailto:struberg@yahoo.de" href="mailto:struberg@yahoo.de">struberg@yahoo.de</a>> wrote:<br>>> Gavin,<br>>><br>>> my main concern is to pass the TCK.<br>>><br>>> 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).<br>>><br>>> 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!<br>>><br>>>
LieGrue,<br>>> strub<br>>><br>>> --- Gavin King <<a ymailto="mailto:gavin.king@gmail.com" href="mailto:gavin.king@gmail.com">gavin.king@gmail.com</a>> schrieb am Fr, 4.12.2009:<br>>><br>>>> Von: Gavin King <<a ymailto="mailto:gavin.king@gmail.com" href="mailto:gavin.king@gmail.com">gavin.king@gmail.com</a>><br>>>> Betreff: Re: [weld-dev] Decorator question<br>>>> An: "Mark Struberg" <<a ymailto="mailto:struberg@yahoo.de" href="mailto:struberg@yahoo.de">struberg@yahoo.de</a>><br>>>> CC: "Marius Bogoevici" <<a ymailto="mailto:mariusb@redhat.com" href="mailto:mariusb@redhat.com">mariusb@redhat.com</a>>, <a ymailto="mailto:weld-dev@lists.jboss.org" href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a><br>>>> Datum: Freitag, 4. Dezember 2009, 17:51<br>>>> Look, I just don't see the usecase<br>>>> for what you're
proposing.<br>>>><br>>>> If you're trying to extend a concrete class, override some<br>>>> of its<br>>>> methods, and delegate some methods back to the superclass,<br>>>> just make<br>>>> your subclass an @Alternative and call super.<br>>>><br>>>> I simply don't see the usecase for having a whole stack of<br>>>> these<br>>>> things. I don't think anyone needs this.<br>>>><br>>>> On Fri, Dec 4, 2009 at 2:21 AM, Mark Struberg <<a ymailto="mailto:struberg@yahoo.de" href="mailto:struberg@yahoo.de">struberg@yahoo.de</a>><br>>>> wrote:<br>>>> > But if (2) is allowed, then the restriction on the<br>>>> Interfaces is pretty restrictive. I cannot see any<br>>>> additional benefit we gain from this restriction and we have<br>>>> to delegate all not-overridden methods via a proxy anyway.<br>>>>
> Can you please give me a hint why this is necessary?<br>>>> ><br>>>> > txs and lieGrue,<br>>>> > strub<br>>>> ><br>>>> ><br>>>> > --- Gavin King <<a ymailto="mailto:gavin.king@gmail.com" href="mailto:gavin.king@gmail.com">gavin.king@gmail.com</a>><br>>>> schrieb am Fr, 4.12.2009:<br>>>> ><br>>>> >> Von: Gavin King <<a ymailto="mailto:gavin.king@gmail.com" href="mailto:gavin.king@gmail.com">gavin.king@gmail.com</a>><br>>>> >> Betreff: Re: [weld-dev] Decorator question<br>>>> >> An: "Marius Bogoevici" <<a ymailto="mailto:mariusb@redhat.com" href="mailto:mariusb@redhat.com">mariusb@redhat.com</a>><br>>>> >> CC: "Mark Struberg" <<a ymailto="mailto:struberg@yahoo.de" href="mailto:struberg@yahoo.de">struberg@yahoo.de</a>>,<br>>>> <a
ymailto="mailto:weld-dev@lists.jboss.org" href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a><br>>>> >> Datum: Freitag, 4. Dezember 2009, 1:56<br>>>> >> On Thu, Dec 3, 2009 at 6:44 PM,<br>>>> >> Marius Bogoevici <<a ymailto="mailto:mariusb@redhat.com" href="mailto:mariusb@redhat.com">mariusb@redhat.com</a>><br>>>> >> wrote:<br>>>> >><br>>>> >> > a) You can still have (2), if<br>>>> AnotherBeanClass<br>>>> >> implements an interface<br>>>> >> > AnInterface. It's just that the set of<br>>>> decorated<br>>>> >> methods is restricted to<br>>>> >> > the ones defined in the interface.<br>>>> >><br>>>> >> Actually, yes, that's true. I should have said<br>>>> that.<br>>>> ><br>>>> >
__________________________________________________<br>>>> > Do You Yahoo!?<br>>>> > Sie sind Spam leid? Yahoo! Mail verfügt über einen<br>>>> herausragenden Schutz gegen Massenmails.<br>>>> > <a href="http://mail.yahoo.com" target="_blank">http://mail.yahoo.com</a><br>>>> ><br>>>><br>>>><br>>>><br>>>> --<br>>>> Gavin King<br>>>> <a ymailto="mailto:gavin.king@gmail.com" href="mailto:gavin.king@gmail.com">gavin.king@gmail.com</a><br>>>> <a href="http://in.relation.to/Bloggers/Gavin" target="_blank">http://in.relation.to/Bloggers/Gavin</a><br>>>> <a href="http://hibernate.org" target="_blank">http://hibernate.org</a><br>>>> <a href="http://seamframework.org" target="_blank">http://seamframework.org</a><br>>>><br>>><br>>> __________________________________________________<br>>> Do You
Yahoo!?<br>>> Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails.<br>>> <a href="http://mail.yahoo.com" target="_blank">http://mail.yahoo.com</a><br>>><br>><br>><br>><br>> --<br>> Gavin King<br>> <a ymailto="mailto:gavin.king@gmail.com" href="mailto:gavin.king@gmail.com">gavin.king@gmail.com</a><br>> <a href="http://in.relation.to/Bloggers/Gavin" target="_blank">http://in.relation.to/Bloggers/Gavin</a><br>> <a href="http://hibernate.org" target="_blank">http://hibernate.org</a><br>> <a href="http://seamframework.org" target="_blank">http://seamframework.org</a><br>><br><br><br><br>-- <br>Gavin King<br><a ymailto="mailto:gavin.king@gmail.com" href="mailto:gavin.king@gmail.com">gavin.king@gmail.com</a><br><a href="http://in.relation.to/Bloggers/Gavin" target="_blank">http://in.relation.to/Bloggers/Gavin</a><br><a href="http://hibernate.org"
target="_blank">http://hibernate.org</a><br><a href="http://seamframework.org" target="_blank">http://seamframework.org</a><br><br>_______________________________________________<br>weld-dev mailing list<br><a ymailto="mailto:weld-dev@lists.jboss.org" href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a><br><a href="https://lists.jboss.org/mailman/listinfo/weld-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/weld-dev</a><br></div></div>
<!-- cg16.c1.mail.mud.yahoo.com compressed/chunked Fri Dec 4 09:18:53 PST 2009 -->
</div><br>
<hr size="1"><FONT face=Arial size=-1>Yahoo! Türkiye açıldı!<br>
Haber, Ekonomi, Videolar, Oyunlar hepsi Yahoo! Türkiye'de!<br><a href="http://tr.yahoo.com/">www.yahoo.com.tr</a></font></body></html>