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
