Answer to question 2.: methodA() should be intercepted on an instance of
B, but not on an instance of A.


Cheers,
Arne

Am 18.10.12 17:41 schrieb "Martin Kouba" unter <[email protected]>:

>Re question 1: yes, both methods should be intercepted (provided
>@Transactional has @Inherited) - see 4.1. "Inheritance of type-level
>metadata":
>If X is annotated with a qualifier type, stereotype or interceptor
>binding type Z then Y inherits the annotation if and only if Z declares
>the @Inherited meta-annotation and neither Y nor any intermediate class
>that is a subclass of X and a superclass of Y declares an annotation of
>type Z.
>
>AFIAK we have a test in CDI TCK 1.1 for this.
>
>M
>
>Dne 18.10.2012 17:34, Mark Struberg napsal(a):
>> I think there are 2 different questions to answer here:
>>
>>
>> @Transactional
>> public class A {
>>    public void methodA();
>> }
>>
>>
>>
>> public class B extends A {
>>    public void methodB();
>> }
>>
>> Question 1: does the @Transactional interceptor get inherited and both
>>methodA() and methodB() get intercepted, or will only methodA() get
>>intercepted? I assume the Transactional annotation itself is marked as
>>inherited.
>>
>>
>> And now for the other case:
>>
>>
>> public class A {
>>    public void methodA();
>> }
>>
>>
>> @Transactional
>> public class B extends A {
>>    public void methodB();
>> }
>>
>> Question 2: does the @Transactional interceptor also affect inherited
>>methods and both methodA() and methodB() get intercepted, or will only
>>methodB() get intercepted?
>>
>>
>>
>>
>> LieGrue,
>> strub
>>
>>
>>
>>
>> ----- Original Message -----
>>> From: Marius Bogoevici <[email protected]>
>>> To: [email protected]
>>> Cc: Martin Kouba <[email protected]>
>>> Sent: Thursday, October 18, 2012 5:17 PM
>>> Subject: Re: @Transactional interceptor ignores derived methods
>>>
>>> IMO the way in which the specification should be interpreted is by
>>>taking into
>>> account the whole set of metadata (inherited and defined on) of a
>>>particular
>>> bean class.
>>>
>>> Therefore: @Transactional being @Inherited IIRC, the binding will be
>>>technically
>>> present on the derived class, so its methods will be considered bound,
>>> regardless whether they are defined on the class itself, inherited
>>>from the
>>> annotated class, or even inherited from a superclass of the annotated
>>>class.
>>>
>>> On 2012-10-18 10:43 AM, Martin Kouba wrote:
>>>>   I think this should work and works for my quick and dirty test.
>>>>
>>>>   Actually the CDI spec only covers inherited interceptor bindings
>>>>(9.5.
>>> Interceptor resolution).
>>>>
>>>>   Dirk, could you provide the source code of your test case so that
>>>>we could
>>> check it?
>>>>
>>>>   Martin
>>>>
>>>>   Dne 16.10.2012 21:13, Jason Porter napsal(a):
>>>>>   That's probably a good place to send it yes. I still think an exact
>>> test
>>>>>   case would be helpful (yes, I know you can't add to a testsuite or
>>> see
>>>>>   what's in there).
>>>>>
>>>>>   On Tue, Oct 16, 2012 at 12:25 PM, Mark Struberg
>>> <[email protected]> wrote:
>>>>>
>>>>>>   Yes, I also have the gut feeling that it should work. I read
>>> through the
>>>>>>   interceptors spec though and didn't find any explicit wording.
>>>>>>   We should redirect this question to the EJB EG which handles the
>>>>>>   interceptors spec, isn't?
>>>>>>
>>>>>>   I remember David saying that for _some_ kind of interceptors it
>>> does not
>>>>>>   work that way. But I don't remember exactly which one.
>>>>>>
>>>>>>   LieGrue,
>>>>>>   strub
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>   ----- Original Message -----
>>>>>>>   From: Jason Porter <[email protected]>
>>>>>>>   To: [email protected]
>>>>>>>   Cc:
>>>>>>>   Sent: Tuesday, October 16, 2012 8:05 PM
>>>>>>>   Subject: Re: @Transactional interceptor ignores derived methods
>>>>>>>
>>>>>>>   Dirk,
>>>>>>>
>>>>>>>    From my understanding of the specs and also from talking with
>>> Pete Muir
>>>>>>   and
>>>>>>>   Mark Struberg because this is an Interceptor it should work
>>> correctly. If
>>>>>>>   it is not, chances are this is a bug in the container and
>>> should be
>>>>>>>   reported.
>>>>>>>
>>>>>>>   We'd love to have some feedback and some contributions in
>>> this area, I
>>>>>>   just
>>>>>>>   went through the test code and it doesn't look like we have
>>> a test with
>>>>>>>   your scenario Dirk. Would you be able to contribute one for us,
>>> please?
>>>>>>>
>>>>>>>   On Tue, Oct 16, 2012 at 9:15 AM, Pete Muir
>>> <[email protected]> wrote:
>>>>>>>
>>>>>>>>     IMO it should apply to superclasses as well.
>>>>>>>>
>>>>>>>>     On 16 Oct 2012, at 14:02, Dirk Weil wrote:
>>>>>>>>
>>>>>>>>     > Hi everybody,
>>>>>>>>     >
>>>>>>>>     >
>>>>>>>>     >
>>>>>>>>     > I started a discussion at
>>>>>>>>    https://community.jboss.org/message/764873#764873
>>>>>>>>     > about the seam transaction interceptor, which is not
>>> handling derived
>>>>>>>>     > methods (see original post further down). Jason
>>> Porter pointed me to
>>>>>>>   this
>>>>>>>>     > mail list, stating that DeltaSpikes Transactional
>>> Interceptor behaves
>>>>>>>   in
>>>>>>>>     the
>>>>>>>>     > same way. What are the reasons for this? Isn't
>>> it normally the
>>>>>>>   case that
>>>>>>>>     a
>>>>>>>>     > user wants transactional behavior regardless of
>>> where the method is
>>>>>>>>     defined
>>>>>>>>     > (base class or derived class)?
>>>>>>>>     >
>>>>>>>>     > Additionally I regard it dangerous if an interceptor
>>> does not behave
>>>>>>>>     like an
>>>>>>>>     > ordinal interceptor (I know: Transactional
>>> intercepts every call, but
>>>>>>>   it
>>>>>>>>     > does different things depending on the class
>>> defining the method
>>>>>>>>     > intercepted).
>>>>>>>>     >
>>>>>>>>     >
>>>>>>>>     >
>>>>>>>>     > Please give me some hint, why the implementation of
>>> Transactional was
>>>>>>>>     done
>>>>>>>>     > in that way.
>>>>>>>>     >
>>>>>>>>     >
>>>>>>>>     >
>>>>>>>>     > Thank you very much and best regards
>>>>>>>>     >
>>>>>>>>     > Dirk Weil
>>>>>>>>     >
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>   -- Jason Porter
>>>>>>>   http://lightguard-jp.blogspot.com
>>>>>>>   http://twitter.com/lightguardjp
>>>>>>>
>>>>>>>   Software Engineer
>>>>>>>   Open Source Advocate
>>>>>>>
>>>>>>>   PGP key id: 926CCFF5
>>>>>>>   PGP key available at: keyserver.net, pgp.mit.edu
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>
>-- 
>Martin Kouba
>JBoss Quality Assurance Engineer
>CDI TCK lead
>E-mail: [email protected]
>Web: www.cz.redhat.com
>Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

Reply via email to