Bug 1109153

Summary: Application Exception information is lost during propagation back to the client
Product: [JBoss] JBoss Enterprise Application Platform 6 Reporter: Shaun Appleton <sappleto>
Component: EJBAssignee: David M. Lloyd <david.lloyd>
Status: CLOSED CURRENTRELEASE QA Contact: Jan Martiska <jmartisk>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 6.2.1CC: cdewolf, kkhan, myarboro, wfink
Target Milestone: DR3   
Target Release: EAP 6.4.0   
Hardware: Unspecified   
OS: Unspecified   
URL: https://c.na7.visual.force.com/apex/Case_View?id=500A000000KOJGi
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1140705 (view as bug list) Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1140705    

Description Shaun Appleton 2014-06-13 11:00:56 UTC
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

Comment 1 wfink 2014-07-07 10:20:56 UTC
From my point of view it is worth to have such business Exceptions as cause at the client side.
1) the customer is able to react on such business related problems
2) will be easier to find the root cause at the client without searching a lot within server logfile specially in cluster environments

Comment 3 Kabir Khan 2014-09-26 12:02:35 UTC
https://github.com/jbossas/jboss-eap/pull/1705

Comment 4 Jan Martiska 2014-10-01 08:28:44 UTC
This fix introduced a regression (https://bugzilla.redhat.com/show_bug.cgi?id=1148015) - the regression will be fixed via that bugzilla. Pushing this one to verified @EAP 6.4.0.DR3.