[cdi-dev] Subclassing?
Stuart Douglas
stuart.w.douglas at gmail.com
Tue Sep 18 19:32:26 EDT 2012
Pete Muir wrote:
> 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.
Yes, although Marius actually did the implementation. At the moment a
A->B->A invocation won't intercept the last A invocation if B is
dependent scoped.
In practice this has not been a problem.
Stuart
>
>> 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
>>>
>>>
>>>
>
>
> _______________________________________________
> 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