Hi everybody,
I have a question concerning exception handling in the case of CMT.
I have done tests with EJB 3.1 and 3.2 deployed in GlassFish (3 or 4)
or in JBoss/wildFly (7.1 or 8.0) and I have the same behavior that
looks strange to me, so maybe there something I’ve not well understood
in the specification.
Below, my test case:
Double bar represents the container and all the beans are local in the
same ear. A, B and C are Stateless Session beans deployed in an ejb-jar
and the CDI bean is deployed in a war module. There is no exception
handling (no try … catch), only exception propagation.
CDI Bean (no tsx) -------------||--------> A (NEVER) --------||------->
B ( REQUIRES_NEW )---------||--------> C ( REQUIRED)
Method of C throws a RuntimeException, the container throws
EJBTransactionRolledbackException and the calling method of B receives
as expected this exception. It’s the first case described in table 7 -
exception handling for a Bean with CMT.
But the container rethrows EJBTransactionRolledbackException to the
calling method of A and after to the method of the CDI bean (or JSF
managed bean). The container should it not rethrow an EJBException and
the calling method of A receives it as described in the second case of
table 7 ?
What I understood from the specification is : B doesn’t catch the
EJBTransactionRolledbackException (system exception) so the method of B
throws this exception which is intercepted by the container which
rethrows a simple EJBException. This seems logic because the
transaction was started before the invocation of B. And the session
bean A is not transactional.
So, have I not well understood the table 7? Or is it a “problem” in
GlassFish and JBoss ? As EJBtransactionRolledbackException is a
subclass of EJBException, can I consider regarding the specification
that the behavior of those implementation is OK? ...
For information, if I don’t mistake, in Java EE 5 in a similar test
case, A received an EJBException.
Thanks by advance,
Regards,
Alex