Hi, There is a bunch of jira to specify subclassing should be used in some cases so i mail here instead of answering all jira. IMO it is specifying too much the technical part: specify the constructor should be called twice is better for a spec IMHO (but this case is not logical at all ;)) Why this need? - Romain _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev

The main difference we get from subclassing is that even 'internal invocations' (contrary to 'external invocations') will invoke the decorator method example public Class A implements X { public void methA() {..} public void methB() { methA(); } } @Decorator public class Adecorator implements X { @Inject @Delegate X x; public void methA(); } If we do _not_ apply subclassing but proxying, then invoking methB will NOT trigger methA from Adecorator. If we DO force subclassing, then a call to methB will also trigger the decorator! But that is contrary to all other EE proxying behaviour so far...

LieGrue, strub ----- Original Message ----- > From: Pete Muir<pmuir(a)redhat.com> > To: Romain Manni-Bucau<rmannibucau(a)gmail.com> > Cc: "cdi-dev@lists.jboss.org"<cdi-dev(a)lists.jboss.org> > Sent: Monday, September 17, 2012 5:58 PM > Subject: Re: [cdi-dev] Subclassing? > > Romain, > > I agree, we can't specify to use subclassing. Please take a look at > https://github.com/jboss/cdi/pull/117 where I've tried to address this, in > terms of what effects people will see. > > On 17 Sep 2012, at 16:54, Romain Manni-Bucau wrote: > >> Hi, >> >> There is a bunch of jira to specify subclassing should be used in some > cases so i mail here instead of answering all jira. >> IMO it is specifying too much the technical part: specify the constructor > should be called twice is better for a spec IMHO (but this case is not logical > at all ;)) >> Why this need? >> >> - Romain >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev

Not sure if the trick with the ThreadLocal would work (aside from being dog slow). A->B->A should all lead to decorator invocations. Is this the case with your impl? (B might be another Decorator or a simple Bean)

LieGrue, strub ----- Original Message ----- > From: Stuart Douglas<stuart.w.douglas(a)gmail.com> > To: Mark Struberg<struberg(a)yahoo.de> > Cc: Pete Muir<pmuir(a)redhat.com>; Romain Manni-Bucau<rmannibucau(a)gmail.com>; "cdi-dev@lists.jboss.org"<cdi-dev(a)lists.jboss.org> > Sent: Monday, September 17, 2012 11:31 PM > Subject: Re: [cdi-dev] Subclassing? > > > > Mark Struberg wrote: >> The main difference we get from subclassing is that even 'internal > invocations' (contrary to 'external invocations') will invoke the > decorator method >> example >> >> public Class A implements X { >> >> >> public void methA() {..} >> public void methB() { methA(); } >> >> } >> >> @Decorator >> public class Adecorator implements X { >> @Inject @Delegate X x; >> >> public void methA(); >> } >> >> If we do _not_ apply subclassing but proxying, then invoking methB will NOT > trigger methA from Adecorator. >> If we DO force subclassing, then a call to methB will also trigger the > decorator! >> But that is contrary to all other EE proxying behaviour so far... > > In weld we currently use a thread local to work around this, so self > invocation does not result in interceptors / decorators running again. > > Stuart > >> >> LieGrue, >> strub >> >> >> >> ----- Original Message ----- >>> From: Pete Muir<pmuir(a)redhat.com> >>> To: Romain Manni-Bucau<rmannibucau(a)gmail.com> >>> Cc: "cdi-dev@lists.jboss.org"<cdi-dev(a)lists.jboss.org> >>> Sent: Monday, September 17, 2012 5:58 PM >>> Subject: Re: [cdi-dev] Subclassing? >>> >>> Romain, >>> >>> I agree, we can't specify to use subclassing. Please take a look at >>> https://github.com/jboss/cdi/pull/117 where I've tried to address > this, in >>> terms of what effects people will see. >>> >>> On 17 Sep 2012, at 16:54, Romain Manni-Bucau wrote: >>> >>>> Hi, >>>> >>>> There is a bunch of jira to specify subclassing should be used in > some >>> cases so i mail here instead of answering all jira. >>>> IMO it is specifying too much the technical part: specify the > constructor >>> should be called twice is better for a spec IMHO (but this case is not > logical >>> at all ;)) >>>> Why this need? >>>> >>>> - Romain >>>> >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev

Hi Stu! +1, fully agree. LieGrue, strub ----- Original Message ----- > From: Stuart Douglas <stuart.w.douglas(a)gmail.com&gt; > To: Mark Struberg <struberg(a)yahoo.de&gt; > Cc: Pete Muir <pmuir(a)redhat.com>; Romain Manni-Bucau <rmannibucau(a)gmail.com>; &quot;cdi-dev(a)lists.jboss.org&quot; <cdi-dev(a)lists.jboss.org&gt; > Sent: Tuesday, September 18, 2012 12:22 AM > Subject: Re: [cdi-dev] Subclassing? > > > > Mark Struberg wrote: >> Not sure if the trick with the ThreadLocal would work (aside from being dog > slow). >> A->B->A should all lead to decorator invocations. Is this the case > with your impl? (B might be another Decorator or a simple Bean) > > Depends if B is a normal scoped bean or not. I agree this is not ideal. > > To be honest I think it may actually be better to tighten the > requirements for intercepted/decorated beans to allow interception to be > implemented via a proxy. The way the CDI 1.0 spec was written this was > not really possible to do and still be spec compliant (although the TCK > did not test this), but we could change to 1.1 spec to require all > intercepted classes to meet the proxiability requirements. > > Basically as I see it the pros/cons of each are: > > Subclassing: > > Pros: > 1. Can use reflection to read fields / bean can have public fields > 2. No proxiability requirement > 3. Constructor is only called once > > Cons: > 4. Self invocation cannot be handled consistently > 5. Implementation is more complex > 6. For normal scoped beans the bean has to be proxied anyway, so there > is no advantage > > > Proxying: > > Pros: > 7. Consistent with all other interceptor behavior > 8. Self invocation works as expected > > Cons: > 9. Bean must meet proxiability requirements (although you can get around > this with JVM specific hacks) > 10. Constructor will be called twice > > I do not consider 1. to be worth considering as a real advantage (public > fields == yuck). Basically the only advantage that sub classing has is > when you are dealing with a dependent scoped bean that would not meet > the proxyability requirements. I think in this case adding a default > constructor to enable the bean to be proxied is not a big deal. > > Stuart > > >> >> LieGrue, >> strub >> >> >> >> >> ----- Original Message ----- >>> From: Stuart Douglas&lt;stuart.w.douglas(a)gmail.com&gt; >>> To: Mark Struberg&lt;struberg(a)yahoo.de&gt; >>> Cc: Pete Muir&lt;pmuir(a)redhat.com&gt;; Romain > Manni-Bucau&lt;rmannibucau(a)gmail.com&gt;; > &quot;cdi-dev@lists.jboss.org&quot;&lt;cdi-dev(a)lists.jboss.org&gt; >>> Sent: Monday, September 17, 2012 11:31 PM >>> Subject: Re: [cdi-dev] Subclassing? >>> >>> >>> >>> Mark Struberg wrote: >>>> The main difference we get from subclassing is that even > 'internal >>> invocations' (contrary to 'external invocations') will > invoke the >>> decorator method >>>> example >>>> >>>> public Class A implements X { >>>> >>>> >>>> public void methA() {..} >>>> public void methB() { methA(); } >>>> >>>> } >>>> >>>> @Decorator >>>> public class Adecorator implements X { >>>> @Inject @Delegate X x; >>>> >>>> public void methA(); >>>> } >>>> >>>> If we do _not_ apply subclassing but proxying, then invoking > methB will NOT >>> trigger methA from Adecorator. >>>> If we DO force subclassing, then a call to methB will also > trigger the >>> decorator! >>>> But that is contrary to all other EE proxying behaviour so far... >>> >>> In weld we currently use a thread local to work around this, so self >>> invocation does not result in interceptors / decorators running again. >>> >>> Stuart >>> >>>> >>>> LieGrue, >>>> strub >>>> >>>> >>>> >>>> ----- Original Message ----- >>>>> From: Pete Muir&lt;pmuir(a)redhat.com&gt; >>>>> To: Romain Manni-Bucau&lt;rmannibucau(a)gmail.com&gt; >>>>> Cc: > &quot;cdi-dev@lists.jboss.org&quot;&lt;cdi-dev(a)lists.jboss.org&gt; >>>>> Sent: Monday, September 17, 2012 5:58 PM >>>>> Subject: Re: [cdi-dev] Subclassing? >>>>> >>>>> Romain, >>>>> >>>>> I agree, we can't specify to use subclassing. Please take > a look at >>>>> https://github.com/jboss/cdi/pull/117 where I've tried to > address >>> this, in >>>>> terms of what effects people will see. >>>>> >>>>> On 17 Sep 2012, at 16:54, Romain Manni-Bucau wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> There is a bunch of jira to specify subclassing should > be used in >>> some >>>>> cases so i mail here instead of answering all jira. >>>>>> IMO it is specifying too much the technical part: > specify the >>> constructor >>>>> should be called twice is better for a spec IMHO (but this > case is not >>> logical >>>>> at all ;)) >>>>>> Why this need? >>>>>> >>>>>> - Romain >>>>>> >>>>>> _______________________________________________ >>>>>> cdi-dev mailing list >>>>>> cdi-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> _______________________________________________ >>>>> cdi-dev mailing list >>>>> cdi-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >

________________________________ From: Joseph Bergmark <bergmark(a)us.ibm.com&gt; To: Pete Muir <pmuir(a)redhat.com&gt; Cc: &quot;cdi-dev(a)lists.jboss.org&quot; <cdi-dev(a)lists.jboss.org&gt; Sent: Tuesday, September 18, 2012 3:35 PM Subject: Re: [cdi-dev] Subclassing? FWIW I agree with Mark & Stu, but isn't backwards compatibility a concern here for implementations that previously supported subclassing? Pete Muir ---09/18/2012 05:01:07 AM---I'm happy to go with whatever you guys agree on here :-) Marius, I guess you are the only dissenter Pete Muir <pmuir(a)redhat.com&gt; Mark Struberg <struberg(a)yahoo.de&gt;, &quot;cdi-dev(a)lists.jboss.org&quot; <cdi-dev(a)lists.jboss.org&gt; 09/18/2012 05:01 AM Re: [cdi-dev] Subclassing? cdi-dev-bounces(a)lists.jboss.org ________________________________ I'm happy to go with whatever you guys agree on here :-) Marius, I guess you are the only dissenter now :-) WDYT? On 18 Sep 2012, at 07:46, Mark Struberg wrote: > Hi Stu! > > +1, fully agree. > > > LieGrue, > strub > > > > ----- Original Message ----- >> From: Stuart Douglas <stuart.w.douglas(a)gmail.com&gt; >> To: Mark Struberg <struberg(a)yahoo.de&gt; >> Cc: Pete Muir <pmuir(a)redhat.com>; Romain Manni-Bucau <rmannibucau(a)gmail.com>; &quot;cdi-dev(a)lists.jboss.org&quot; <cdi-dev(a)lists.jboss.org&gt; >> Sent: Tuesday, September 18, 2012 12:22 AM >> Subject: Re: [cdi-dev] Subclassing? >> >> >> >> Mark Struberg wrote: >>> Not sure if the trick with the ThreadLocal would work (aside from being dog >> slow). >>> A->B->A should all lead to decorator invocations. Is this the case >> with your impl? (B might be another Decorator or a simple Bean) >> >> Depends if B is a normal scoped bean or not. I agree this is not ideal. >> >> To be honest I think it may actually be better to tighten the >> requirements for intercepted/decorated beans to allow interception to be >> implemented via a proxy. The way the CDI 1.0 spec was written this was >> not really possible to do and still be spec compliant (although the TCK >> did not test this), but we could change to 1.1 spec to require all >> intercepted classes to meet the proxiability requirements. >> >> Basically as I see it the pros/cons of each are: >> >> Subclassing: >> >> Pros: >> 1. Can use reflection to read fields / bean can have public fields >> 2. No proxiability requirement >> 3. Constructor is only called once >> >> Cons: >> 4. Self invocation cannot be handled consistently >> 5. Implementation is more complex >> 6. For normal scoped beans the bean has to be proxied anyway, so there >> is no advantage >> >> >> Proxying: >> >> Pros: >> 7. Consistent with all other interceptor behavior >> 8. Self invocation works as expected >> >> Cons: >> 9. Bean must meet proxiability requirements (although you can get around >> this with JVM specific hacks) >> 10. Constructor will be called twice >> >> I do not consider 1. to be worth considering as a real advantage (public >> fields == yuck). Basically the only advantage that sub classing has is >> when you are dealing with a dependent scoped bean that would not meet >> the proxyability requirements. I think in this case adding a default >> constructor to enable the bean to be proxied is not a big deal. >> >> Stuart >> >> >>> >>> LieGrue, >>> strub >>> >>> >>> >>> >>> ----- Original Message ----- >>>> From: Stuart Douglas&lt;stuart.w.douglas(a)gmail.com&gt; >>>> To: Mark Struberg&lt;struberg(a)yahoo.de&gt; >>>> Cc: Pete Muir&lt;pmuir(a)redhat.com&gt;; Romain >> Manni-Bucau&lt;rmannibucau(a)gmail.com&gt;; >> &quot;cdi-dev@lists.jboss.org&quot;&lt;cdi-dev(a)lists.jboss.org&gt; >>>> Sent: Monday, September 17, 2012 11:31 PM >>>> Subject: Re: [cdi-dev] Subclassing? >>>> >>>> >>>> >>>> Mark Struberg wrote: >>>>>    The main difference we get from subclassing is that even >> 'internal >>>> invocations' (contrary to 'external invocations') will >> invoke the >>>> decorator method >>>>>    example >>>>> >>>>>    public Class A implements X { >>>>> >>>>> >>>>>       public void methA() {..} >>>>>       public void methB() { methA(); } >>>>> >>>>>    } >>>>> >>>>>    @Decorator >>>>>    public class Adecorator implements X { >>>>>       @Inject @Delegate X x; >>>>> >>>>>       public void methA(); >>>>>    } >>>>> >>>>>    If we do _not_ apply subclassing but proxying, then invoking >> methB will NOT >>>> trigger methA from Adecorator. >>>>>    If we DO force subclassing, then a call to methB will also >> trigger the >>>> decorator! >>>>>    But that is contrary to all other EE proxying behaviour so far... >>>> >>>> In weld we currently use a thread local to work around this, so self >>>> invocation does not result in interceptors / decorators running again. >>>> >>>> Stuart >>>> >>>>> >>>>>    LieGrue, >>>>>    strub >>>>> >>>>> >>>>> >>>>>    ----- Original Message ----- >>>>>>    From: Pete Muir&lt;pmuir(a)redhat.com&gt; >>>>>>    To: Romain Manni-Bucau&lt;rmannibucau(a)gmail.com&gt; >>>>>>    Cc: >> &quot;cdi-dev@lists.jboss.org&quot;&lt;cdi-dev(a)lists.jboss.org&gt; >>>>>>    Sent: Monday, September 17, 2012 5:58 PM >>>>>>    Subject: Re: [cdi-dev] Subclassing? >>>>>> >>>>>>    Romain, >>>>>> >>>>>>    I agree, we can't specify to use subclassing. Please take >> a look at >>>>>>   https://github.com/jboss/cdi/pull/117 where I've tried to >> address >>>> this, in >>>>>>    terms of what effects people will see. >>>>>> >>>>>>    On 17 Sep 2012, at 16:54, Romain Manni-Bucau wrote: >>>>>> >>>>>>>      Hi, >>>>>>> >>>>>>>      There is a bunch of jira to specify subclassing should >> be used in >>>> some >>>>>>    cases so i mail here instead of answering all jira. >>>>>>>      IMO it is specifying too much the technical part:   >> specify the >>>> constructor >>>>>>    should be called twice is better for a spec IMHO (but this >> case is not >>>> logical >>>>>>    at all ;)) >>>>>>>      Why this need? >>>>>>> >>>>>>>      - Romain >>>>>>> >>>>>>>      _______________________________________________ >>>>>>>      cdi-dev mailing list >>>>>>>     cdi-dev(a)lists.jboss.org >>>>>>>     https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>    _______________________________________________ >>>>>>    cdi-dev mailing list >>>>>>   cdi-dev(a)lists.jboss.org >>>>>>   https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>> >>>>>    _______________________________________________ >>>>>    cdi-dev mailing list >>>>>   cdi-dev(a)lists.jboss.org >>>>>   https://lists.jboss.org/mailman/listinfo/cdi-dev >> _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev

On 18 Sep 2012, at 15:31, Mark Struberg wrote: > > Well, I think that is not exactly the case here. > > In OWB I once tried subclassing but reverted it back to a proxy based solution because I couldn't get it right. > Status OWB: proxy for Decorators > > In Weld it once was a proxy, then they moved to subclassing with a few hacks because the CDI specified behaviour is a mixture between subclassing and proxy effects. As I already showed (A->B->A) this solution is only 70% working (with nasty side effects for the other 30%). It also cannot work any @NormalScoped beans and for @Dependent beans which are intercepted. And I fear it's pretty hard to get this implemented > Status Weld: proxy in older versions, partially broken subclassing in newer versions > > > Stu, Pete, is this summary correct? Stuart is the best person to ask.

> If so then I see not much reason for not not moving back to proxies for Decorators again. > LieGrue, > strub > > > >> ________________________________ >> From: Joseph Bergmark&lt;bergmark(a)us.ibm.com&gt; >> To: Pete Muir&lt;pmuir(a)redhat.com&gt; >> Cc: &quot;cdi-dev@lists.jboss.org&quot;&lt;cdi-dev(a)lists.jboss.org&gt; >> Sent: Tuesday, September 18, 2012 3:35 PM >> Subject: Re: [cdi-dev] Subclassing? >> >> >> FWIW I agree with Mark& Stu, but isn't backwards compatibility a concern here for implementations that previously supported subclassing? >> >> Pete Muir ---09/18/2012 05:01:07 AM---I'm happy to go with whatever you guys agree on here :-) Marius, I guess you are the only dissenter >> >> >> >> >> Pete Muir&lt;pmuir(a)redhat.com&gt; >> >> >> Mark Struberg&lt;struberg(a)yahoo.de&gt;, >> >> >> &quot;cdi-dev@lists.jboss.org&quot;&lt;cdi-dev(a)lists.jboss.org&gt; >> >> >> 09/18/2012 05:01 AM >> >> >> Re: [cdi-dev] Subclassing? >> >> >> cdi-dev-bounces(a)lists.jboss.org >> ________________________________ >> >> >> >> I'm happy to go with whatever you guys agree on here :-) >> >> Marius, I guess you are the only dissenter now :-) WDYT? >> >> On 18 Sep 2012, at 07:46, Mark Struberg wrote: >> >>> Hi Stu! >>> >>> +1, fully agree. >>> >>> >>> LieGrue, >>> strub >>> >>> >>> >>> ----- Original Message ----- >>>> From: Stuart Douglas&lt;stuart.w.douglas(a)gmail.com&gt; >>>> To: Mark Struberg&lt;struberg(a)yahoo.de&gt; >>>> Cc: Pete Muir&lt;pmuir(a)redhat.com&gt;; Romain Manni-Bucau&lt;rmannibucau(a)gmail.com&gt;; &quot;cdi-dev@lists.jboss.org&quot;&lt;cdi-dev(a)lists.jboss.org&gt; >>>> Sent: Tuesday, September 18, 2012 12:22 AM >>>> Subject: Re: [cdi-dev] Subclassing? >>>> >>>> >>>> >>>> Mark Struberg wrote: >>>>> Not sure if the trick with the ThreadLocal would work (aside from being dog >>>> slow). >>>>> A->B->A should all lead to decorator invocations. Is this the case >>>> with your impl? (B might be another Decorator or a simple Bean) >>>> >>>> Depends if B is a normal scoped bean or not. I agree this is not ideal. >>>> >>>> To be honest I think it may actually be better to tighten the >>>> requirements for intercepted/decorated beans to allow interception to be >>>> implemented via a proxy. The way the CDI 1.0 spec was written this was >>>> not really possible to do and still be spec compliant (although the TCK >>>> did not test this), but we could change to 1.1 spec to require all >>>> intercepted classes to meet the proxiability requirements. >>>> >>>> Basically as I see it the pros/cons of each are: >>>> >>>> Subclassing: >>>> >>>> Pros: >>>> 1. Can use reflection to read fields / bean can have public fields >>>> 2. No proxiability requirement >>>> 3. Constructor is only called once >>>> >>>> Cons: >>>> 4. Self invocation cannot be handled consistently >>>> 5. Implementation is more complex >>>> 6. For normal scoped beans the bean has to be proxied anyway, so there >>>> is no advantage >>>> >>>> >>>> Proxying: >>>> >>>> Pros: >>>> 7. Consistent with all other interceptor behavior >>>> 8. Self invocation works as expected >>>> >>>> Cons: >>>> 9. Bean must meet proxiability requirements (although you can get around >>>> this with JVM specific hacks) >>>> 10. Constructor will be called twice >>>> >>>> I do not consider 1. to be worth considering as a real advantage (public >>>> fields == yuck). Basically the only advantage that sub classing has is >>>> when you are dealing with a dependent scoped bean that would not meet >>>> the proxyability requirements. I think in this case adding a default >>>> constructor to enable the bean to be proxied is not a big deal. >>>> >>>> Stuart >>>> >>>> >>>>> LieGrue, >>>>> strub >>>>> >>>>> >>>>> >>>>> >>>>> ----- Original Message ----- >>>>>> From: Stuart Douglas&lt;stuart.w.douglas(a)gmail.com&gt; >>>>>> To: Mark Struberg&lt;struberg(a)yahoo.de&gt; >>>>>> Cc: Pete Muir&lt;pmuir(a)redhat.com&gt;; Romain >>>> Manni-Bucau&lt;rmannibucau(a)gmail.com&gt;; >>>> &quot;cdi-dev@lists.jboss.org&quot;&lt;cdi-dev(a)lists.jboss.org&gt; >>>>>> Sent: Monday, September 17, 2012 11:31 PM >>>>>> Subject: Re: [cdi-dev] Subclassing? >>>>>> >>>>>> >>>>>> >>>>>> Mark Struberg wrote: >>>>>>> The main difference we get from subclassing is that even >>>> 'internal >>>>>> invocations' (contrary to 'external invocations') will >>>> invoke the >>>>>> decorator method >>>>>>> example >>>>>>> >>>>>>> public Class A implements X { >>>>>>> >>>>>>> >>>>>>> public void methA() {..} >>>>>>> public void methB() { methA(); } >>>>>>> >>>>>>> } >>>>>>> >>>>>>> @Decorator >>>>>>> public class Adecorator implements X { >>>>>>> @Inject @Delegate X x; >>>>>>> >>>>>>> public void methA(); >>>>>>> } >>>>>>> >>>>>>> If we do _not_ apply subclassing but proxying, then invoking >>>> methB will NOT >>>>>> trigger methA from Adecorator. >>>>>>> If we DO force subclassing, then a call to methB will also >>>> trigger the >>>>>> decorator! >>>>>>> But that is contrary to all other EE proxying behaviour so far... >>>>>> In weld we currently use a thread local to work around this, so self >>>>>> invocation does not result in interceptors / decorators running again. >>>>>> >>>>>> Stuart >>>>>> >>>>>>> LieGrue, >>>>>>> strub >>>>>>> >>>>>>> >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>>> From: Pete Muir&lt;pmuir(a)redhat.com&gt; >>>>>>>> To: Romain Manni-Bucau&lt;rmannibucau(a)gmail.com&gt; >>>>>>>> Cc: >>>> &quot;cdi-dev@lists.jboss.org&quot;&lt;cdi-dev(a)lists.jboss.org&gt; >>>>>>>> Sent: Monday, September 17, 2012 5:58 PM >>>>>>>> Subject: Re: [cdi-dev] Subclassing? >>>>>>>> >>>>>>>> Romain, >>>>>>>> >>>>>>>> I agree, we can't specify to use subclassing. Please take >>>> a look at >>>>>>>> https://github.com/jboss/cdi/pull/117 where I've tried to >>>> address >>>>>> this, in >>>>>>>> terms of what effects people will see. >>>>>>>> >>>>>>>> On 17 Sep 2012, at 16:54, Romain Manni-Bucau wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> There is a bunch of jira to specify subclassing should >>>> be used in >>>>>> some >>>>>>>> cases so i mail here instead of answering all jira. >>>>>>>>> IMO it is specifying too much the technical part: >>>> specify the >>>>>> constructor >>>>>>>> should be called twice is better for a spec IMHO (but this >>>> case is not >>>>>> logical >>>>>>>> at all ;)) >>>>>>>>> Why this need? >>>>>>>>> >>>>>>>>> - Romain >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> cdi-dev mailing list >>>>>>>>> cdi-dev(a)lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>>> _______________________________________________ >>>>>>>> cdi-dev mailing list >>>>>>>> cdi-dev(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> cdi-dev mailing list >>>>>>> cdi-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> >> _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev