[
https://issues.apache.org/jira/browse/OPENEJB-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022209#comment-13022209
]
David Jencks commented on OPENEJB-1091:
---------------------------------------
Hi Mohan,
Your patch is a good start but I think it ignores the hard part of the problem.
Somewhere (I'm not exactly sure where) there is code that looks at exceptions
and rewrites them into local or remote exceptions depending on how the method
was accessed (through the local or remote interface). Previously this code was
expecting a remote TxRolledBackException and for local interface access it
would convert it to a local javax.ejb.TransactionRolledbackLocalException. I
think we have to find that code and change it so it makes the other conversion.
Or did you find the code and it already converts the new
TransactionRolledbackLocalException to a remote TransactionRolledbackException?
> Cause of RollbackException swallowed
> ------------------------------------
>
> Key: OPENEJB-1091
> URL: https://issues.apache.org/jira/browse/OPENEJB-1091
> Project: OpenEJB
> Issue Type: Bug
> Components: server
> Affects Versions: 3.0-beta-2
> Reporter: Geoff Callender
> Assignee: Jean-Louis MONTEIRO
> Fix For: 3.0
>
> Attachments: open-ejb_1091.patch
>
>
> This is linked to OPENEJB-782 where the problem was first noted. The flaw
> described there still exists in 3.1, ie. the client still has no way of
> determining the reason a rollback occurred.
> When the client digs into the exception cause, all it finds is
> javax.transaction.RollbackException. The originating
> javax.persistence.PersistenceException or java.sql.SQLException is missing.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
