[jira] [Commented] (GERONIMO-4576) Make persistence exceptions more visible to client
[ https://issues.apache.org/jira/browse/GERONIMO-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13598790#comment-13598790 ] andrew shililday commented on GERONIMO-4576: Freeman, Hi. Did you manage to get around the problem in any way without changing the source code? I'm not really in a position to change the code, but in my application I really need to differentiate between OptimisticLockExceptions versus more critical underlying persistence provider or jdbc exceptions. 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 Priority: Minor Fix For: Wish List 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-4576) Make persistence exceptions more visible to client
[ https://issues.apache.org/jira/browse/GERONIMO-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13598798#comment-13598798 ] Freeman Fang commented on GERONIMO-4576: Hi Andrew, No, I must change the source code for my case. Cheers Freeman 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 Priority: Minor Fix For: Wish List 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] (take 2) Release genesis-2.1 and xbean-3.13
+1 for genesis. -1 for xbean. Unless I'm looking at a cached version, there are still snaphot repositories defined in the root pom (marked with !-- Can be removed once Genesis SNAPSHOT dependency is removed --). Jarek On Fri, Mar 8, 2013 at 3:12 PM, Mark Struberg strub...@yahoo.de wrote: Hi! I'd like to call a VOTE for the re-roll on genesis-2.1 and xbean-3.13. I fixed the issues catched by Jarek, txs 4 the catch! The Maven Staging Repo which contains both releases (xbean needs genesis): https://repository.apache.org/content/repositories/orgapachegeronimo-004/ SVN source tag for genesis: https://svn.apache.org/repos/asf/geronimo/genesis/tags/genesis-2.1/ SVN source tag for xbean: https://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-3.13/ Source releases (plus hashes) are available under: https://repository.apache.org/content/repositories/orgapachegeronimo-004/org/apache/geronimo/genesis/genesis/2.1/ https://repository.apache.org/content/repositories/orgapachegeronimo-004/org/apache/xbean/xbean/3.13/ My PGP release key 2FDB81B1 is available at https://svn.apache.org/repos/asf/geronimo/KEYS Kevan is so kind and will collect the JIRA bits (I have absolutely no oversight about how to gather all the needed infos there). The VOTE will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 veto (and reason why) There is a small (and old) guide for testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html In practice it's as easy as adding a profile to your ~/.m2/settings.xml which contains the repository with the URL pointing to the staging repo as posted above. txs and LieGrue, strub
Re: [VOTE] (take 2) Release genesis-2.1 and xbean-3.13
is this snapshot repo an issue? it is not used and that's the apache snapshot repo (should even be in the apache parent pom IIRC) *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/3/11 Jarek Gawor jga...@gmail.com +1 for genesis. -1 for xbean. Unless I'm looking at a cached version, there are still snaphot repositories defined in the root pom (marked with !-- Can be removed once Genesis SNAPSHOT dependency is removed --). Jarek On Fri, Mar 8, 2013 at 3:12 PM, Mark Struberg strub...@yahoo.de wrote: Hi! I'd like to call a VOTE for the re-roll on genesis-2.1 and xbean-3.13. I fixed the issues catched by Jarek, txs 4 the catch! The Maven Staging Repo which contains both releases (xbean needs genesis): https://repository.apache.org/content/repositories/orgapachegeronimo-004/ SVN source tag for genesis: https://svn.apache.org/repos/asf/geronimo/genesis/tags/genesis-2.1/ SVN source tag for xbean: https://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-3.13/ Source releases (plus hashes) are available under: https://repository.apache.org/content/repositories/orgapachegeronimo-004/org/apache/geronimo/genesis/genesis/2.1/ https://repository.apache.org/content/repositories/orgapachegeronimo-004/org/apache/xbean/xbean/3.13/ My PGP release key 2FDB81B1 is available at https://svn.apache.org/repos/asf/geronimo/KEYS Kevan is so kind and will collect the JIRA bits (I have absolutely no oversight about how to gather all the needed infos there). The VOTE will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 veto (and reason why) There is a small (and old) guide for testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html In practice it's as easy as adding a profile to your ~/.m2/settings.xml which contains the repository with the URL pointing to the staging repo as posted above. txs and LieGrue, strub
