On Jun 25, 2008, at 4:42 PM, Karsten Ohme wrote:
David Blevins schrieb:
On Jun 25, 2008, at 9:38 AM, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]
> wrote:
I run a test which provokes an application exception. The
exception is
defined in the same module and annotated with
@ApplicationException(rollback=true). The Exception is rolled back.
Fine.
Another test checks also an exception. The exception is not from
an EJB
module, but from an imported API. The exception has the same
annotation,
but the transaction is not rolled back. It seams to me that the
annotation in this class is ignored.
We definitely don't check the annotations at runtime, simply
because you can override them via the deployment descriptor so the
"merged" set of meta data is the only safe thing to execute against
at runtime (not if we expect to pass the tck anyway ;). But as you
point out we just check the module itself for @ApplicationException
annotated classes.
I don't have them annotated in the deployment descriptor. This would
be very uncomfortable, because each module which uses the exception
from the other module would have to do this.
Agree, that would be an unnecessary pain.
Hmm...
Is the annotated exception class listed in any of the throws
clauses of the business interface methods in module B?
Yes, it is.
(where module A has the exception class, module B does not)
If so, we could expand our support to looking there too in addition
to scraping the module jar.
Would be nice.
Ok. Implemented that technique. Should you decide to override the app
exception in the deployment descriptor of module B, for example, that
will work too.
New 3.1-SNAPSHOT binaries have been published. Give it a try and let
us know if it works out.
-David