Because it belongs to an archived project. Jira admins can restore projects from the archive.
Make sure JTA / Java EE plays well with Bean Validation + JPA when exceptions occurs
Description
Not a BV issue per se but when a ConstraintViolationException is raised during a flush operation in JPA and the flush operation is triggered during the beforeCommit phase of the Tx, there is a loophole
JPA wraps the exception into a RollbackException (bad in itself btw as it's not consistent with what happens when the user manually calls flush())
JPA mark the Tx as setRollbackOnly()
Some Tx managers (eg. JBoss TS) do not report the cause exception because it considers setRollbackOnly and its associated stacktrace as more important (information wise) as the original exception.
A method like setRollbackOnly(rootException) could solve the problem.
Major
Not a BV issue per se but when a ConstraintViolationException is raised during a flush operation in JPA and the flush operation is triggered during the beforeCommit phase of the Tx, there is a loophole
JPA wraps the exception into a RollbackException (bad in itself btw as it's not consistent with what happens when the user manually calls flush())
JPA mark the Tx as setRollbackOnly()
Some Tx managers (eg. JBoss TS) do not report the cause exception because it considers setRollbackOnly and its associated stacktrace as more important (information wise) as the original exception.
A method like setRollbackOnly(rootException) could solve the problem.
For more background information, see
https://jira.jboss.org/browse/JBTM-575