[cdi-dev] Subclassing?
Joseph Bergmark
bergmark at us.ibm.com
Tue Sep 18 09:35:29 EDT 2012
FWIW I agree with Mark & Stu, but isn't backwards compatibility a concern
here for implementations that previously supported subclassing?
Sincerely,
Joe
From: Pete Muir <pmuir at redhat.com>
To: Mark Struberg <struberg at yahoo.de>,
Cc: "cdi-dev at lists.jboss.org" <cdi-dev at lists.jboss.org>
Date: 09/18/2012 05:01 AM
Subject: Re: [cdi-dev] Subclassing?
Sent by: 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20120918/ba3203bb/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20120918/ba3203bb/attachment-0002.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20120918/ba3203bb/attachment-0003.gif
More information about the cdi-dev
mailing list