[cdi-dev] Subclassing?

Pete Muir pmuir at redhat.com
Tue Sep 18 10:34:40 EDT 2012


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 <bergmark at us.ibm.com>
>> To: Pete Muir <pmuir at redhat.com> 
>> Cc: "cdi-dev at lists.jboss.org" <cdi-dev at lists.jboss.org> 
>> 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 at redhat.com> 
>> 
>> 
>> Mark Struberg <struberg at yahoo.de>,  
>> 
>> 
>> "cdi-dev at lists.jboss.org" <cdi-dev at lists.jboss.org> 
>> 
>> 
>> 09/18/2012 05:01 AM 
>> 
>> 
>> Re: [cdi-dev] Subclassing? 
>> 
>> 
>> cdi-dev-bounces at 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 at gmail.com>
>>>> To: Mark Struberg <struberg at yahoo.de>
>>>> Cc: Pete Muir <pmuir at redhat.com>; Romain Manni-Bucau <rmannibucau at gmail.com>; "cdi-dev at lists.jboss.org" <cdi-dev at lists.jboss.org>
>>>> 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<stuart.w.douglas at gmail.com>
>>>>>> To: Mark Struberg<struberg at yahoo.de>
>>>>>> Cc: Pete Muir<pmuir at redhat.com>; Romain 
>>>> Manni-Bucau<rmannibucau at gmail.com>; 
>>>> "cdi-dev at lists.jboss.org"<cdi-dev at 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 at redhat.com>
>>>>>>>>    To: Romain Manni-Bucau<rmannibucau at gmail.com>
>>>>>>>>    Cc: 
>>>> "cdi-dev at lists.jboss.org"<cdi-dev at 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 at lists.jboss.org
>>>>>>>>>     https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>    _______________________________________________
>>>>>>>>    cdi-dev mailing list
>>>>>>>>   cdi-dev at lists.jboss.org
>>>>>>>>   https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>> 
>>>>>>>    _______________________________________________
>>>>>>>    cdi-dev mailing list
>>>>>>>   cdi-dev at lists.jboss.org
>>>>>>>   https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>> 
>> 
>> 
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>> 
>> 
>> 
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>> 
>> 
>> 




More information about the cdi-dev mailing list