Thanks Mark.
Sent from my iPhone
On Oct 18, 2012, at 14:00, Mark Struberg <strub...@yahoo.de> wrote:
> I forwarded the question to the EJB EG which maintains the interceptors
> specification.
>
> Will ping back once they know more about it.
>
> LieGrue,
> strub
>
>
>
>
> ----- Original Message -----
>> From: Mark Struberg <strub...@yahoo.de>
>> To: "deltaspike-users@incubator.apache.org"
>> <deltaspike-users@incubator.apache.org>
>> Cc:
>> Sent: Thursday, October 18, 2012 8:25 PM
>> Subject: Re: @Transactional interceptor ignores derived methods
>>
>> 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 <arne.limb...@openknowledge.de>
>>> To: "deltaspike-users@incubator.apache.org"
>> <deltaspike-users@incubator.apache.org>
>>> 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
>>> <mko...@redhat.com>:
>>>
>>>> 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 <marius.bogoev...@gmail.com>
>>>>>> To: deltaspike-users@incubator.apache.org
>>>>>> Cc: Martin Kouba <mko...@redhat.com>
>>>>>> 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
>>>>>> <strub...@yahoo.de> 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
>>> <lightguard...@gmail.com>
>>>>>>>>>> To: deltaspike-users@incubator.apache.org
>>>>>>>>>> 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
>>>>>> <pm...@redhat.com> 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: mko...@redhat.com
>>>> Web: www.cz.redhat.com
>>>> Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
>>>
>>
