Yes, that seems to be the most expected interpretation. This is also what OWB is doing right now.
But by reading the interceptors spec I was not able to find any paragraph which exactly defines this behaviour. So we might better reach out to the EJB EG with this question. LieGrue, strub ----- Original Message ----- > From: Arne Limburg <[email protected]> > To: "[email protected]" > <[email protected]> > Cc: > Sent: Thursday, October 18, 2012 8:20 PM > Subject: Re: @Transactional interceptor ignores derived methods > > 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 >
