Background: Migrating an application from EAP 4 to EAP 6

Description of problem:

In EAP 4 JBossTransactionRolledbackException was used. This no longer exists in 6 so TransactionRolledbackException is now used.


When using EAP 6.2 a client receives the TransactionRolledbackException but is is stripped of the underlying issue that caused the exception.



Debugging shows a custom ProcessException is thrown initially on the EJB side (in the business classes), but it is not propagated to the client calling the EJB. Hence the application at the end is not able to show the error message.

Further debugging points to where the message is lost -
In EAP 6 :
- ProcessException is raised in a business class called by the EJB 
- the class AtomicAction(TwoPhaseCoordinator).beforeCompletion : the ProcessException is passed to the calling classes
- the class TransactionImple.commitAndDissociate : raises a rollbackException with ProcessException as cause
- CMTorg.jboss.as.ejb3.tx.CMTTxInterceptor : raises javax.ejb.EJBTransactionRolledbackException with RolbackException as cause ,  which has ProcessException as cause

This exception arrives in the class org.jboss.as.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories where at line 69 a new TransactionRolledbackException is thrown with only the message :
            } catch (EJBTransactionRolledbackException e) {
                throw new TransactionRolledbackException(e.getMessage());
            }
starting from this point the exception propagated is a TransactionRolledbackException that has no cause .. 


org.jboss.as.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories[1] has the following comments in it

053     /**
054      * We need to return a CreateException to the client.
055      * <p/>
056      * Rather than forcing all create exceptions everywhere to propagate, and generally making a mess, we stash
057      * the exception here, and then re-throw it from the exception transforming interceptor.
058      */

So it looks like a conscious design decision not to propagate the exception (and the cause) was made when it was written.

Note AS7-5432[2] was raised to enable propagation for the local case.
Can the remote case be fixed as well.


[1] http://grepcode.com/file/repository.jboss.org/nexus/content/repositories/releases/org.jboss.as/jboss-as-ejb3/7.1.0.CR1b/org/jboss/as/ejb3/component/interceptors/EjbExceptionTransformingInterceptorFactories.java
[2] https://issues.jboss.org/browse/AS7-5432