The problematic scenario is following

1. a client server starts a transaction and call the other server with the txn context
2. the other server makes some actions (resources are enlisted and some work is done)
3. the client server calls prepare/commit for ejb remoting resource pointing on the other server
4. the other server tries to prepare/commit its subordinate transaction but it fails - a resource has a trouble and throws an exception
5. server should provide txn exception and add exception by resource to client
6. the client should be provided with whole exception chain - meaning get data about the exception, exception cause and suppressed exceptions (suppressed exceptions contains the exception thrown by client)

Enhancement in 7.1.0 brings new handling of exception propagation from the server to client. This new behavior is implemented in Wildfly Transaction Client (https://github.com/wildfly/wildfly-transaction-client) and changes the way of passing raw exception (exception and cause etc. in raw form) to having every exception being cloned to RemoteExceptionCause (implementation in wildfly-common project) and all fields of the original exception are "serialized" to string form and put as message to the newly created RemoteExceptionCause. The new exception gets the same stacktrace as the original one.

The behavior is expected by customer (see https://bugzilla.redhat.com/show_bug.cgi?id=1435549)

This case is follow-up to JBEAP-7957