|
Problem |
TransactionRollbackException is thrown from the websphere
container, but not the nested original exception in the back stack trace,
why? |
|
Solution |
Unfortunately, this behavior is caused by some rules
in the EJB and RMI-IIOP specifications.
The EJB specification says that the container must map all
"unexpected" exceptions (that is, exceptions that have not been declared
as being thrown by the method)
javax.transaction.TransactionRollbackException. When the container
performs this mapping, it nests the "original" exception insidethe
TransactionRolledbackException.
However, the RMI-IIOP specification declares the rules for how
various J2EE exceptions must be encoded when they are sent across a
network. The javax.transaction.TransactionRolledbackException must be
mapped to a CORBA "TRANSACTION_ROLLBACK" exception by the ORB when it is
placed "on the wire." This rule is to allow EJB application servers
to interoperate with legacy CORBA-based systems. This CORBA
exception belongs to a class of exceptions called CORBA "system
exceptions." System exceptions may not contain any nested exceptions; they
can only contain a character string message. Thus when the
TransactionRolledbackException is placed on the wire, the nested
"original" exception is lost since it cannot be encoded in the CORBA
system exception. When the client ORB receives the CORBA exception,
it converts it back to a javax.transaction.TransactionRolledbackException
but since the nested exception was not included in the data placed on the
wire, the exception on the client side does not contain the nested
"original" exception. |
|
|
|
|
|
|