[
https://issues.apache.org/jira/browse/GERONIMO-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reassigned GERONIMO-4576:
-----------------------------------------
Assignee: Guillaume Nodet
> Make persistence exceptions more visible to client
> --------------------------------------------------
>
> Key: GERONIMO-4576
> URL: https://issues.apache.org/jira/browse/GERONIMO-4576
> Project: Geronimo
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: persistence
> Affects Versions: 2.2
> Environment: Linux, Windows
> Reporter: Joe Bohn
> Assignee: Guillaume Nodet
> Priority: Minor
> Fix For: Wish List
>
> Attachments: GERONIMO-4576-1.patch
>
>
> See http://issues.apache.org/jira/browse/GERONIMO-3907 for details of the
> original problem. That core problem was resolved. However, upon resolution
> it was mentioned that it would be beneficial to report more specific failure
> information back to the client. From GERONIMO-3907:
> Ralf Baumhof - 06/May/08 06:17 AM
> Today if have tested the new Geronimo release 2.1.1 (published on
> 28.04.2008). The problem is now fixed. If the server gets an error on trying
> a commit, this error is now thrown to the web bean.
> Exception text:
> javax.ejb.EJBTransactionRolledbackException: Transaction was rolled back,
> presumably because setRollbackOnly was called during a synchronization:
> Unable to commit: transaction marked for rollback Root Cause:
> javax.transaction.TransactionRolledbackException : Transaction was rolled
> back, presumably because setRollbackOnly was called during a synchronization:
> Unable to commit: transaction marked for rollback
> Unfortunately there is no proper root cause attached to the exception. So the
> cause can only be seen in the server console, but can not be reported to the
> user. It would be very nice if you could change this in a later release.
> Thanks for your help.
> Vincent MATHON - 06/Nov/08 02:03 AM
> I agree that exceptions on the server side should not be thrown to the client
> side since such exceptions types might not be known by the client. However,
> for unit testing purpose, it is useful to attach the root cause to the
> RollBackException. I have modified a few lines in
> org.apache.geronimo.transaction.manager.TransactionImpl.java to attach the
> root cause in case of RollBackException and it works for my unit testing
> purpose (I have not enough background on the java transaction architecture
> topic to submit a patch for production). It would be great to define a
> configuration parameter that permits to provide the root cause to the client
> and keep the current behaviour that does not by default.
> Geoff Callender - 22/Dec/08 03:36 AM
> It's useful for more than unit testing - it's essential to be able to inform
> the client what's wrong with the request. I've added some examples of this to
> https://issues.apache.org/jira/browse/OPENEJB-782 .
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
