Resolution: Won't Fix
Affects Version/s: None
Fix Version/s: None
Last commented by a User:false
(Logged by Ben Alex on behalf of Jukka Palomäki)
ROO-182 provided basic AspectJ-based exception translation of any JPA exceptions into Spring DataAccessExceptions. The present implementation uses the static EntityManagerFactoryUtils.convertJpaAccessExceptionIfPossible(RuntimeException) method. Unfortunately this approach does not provide the ability to unwrap JPA implementation-specific exceptions that may be embedded within the JPA exception.
Spring provides a PersistenceExceptionTranslator interface:
There are various implementations of PersistenceExceptionTranslator, including implementations specific to different JPA implementations. For example, HibernateJpaDialect implements PersistenceExceptionTranslator and provides Hibernate-specific exception-to-DataAccessException resolution.
Because the optimal PersistenceExceptionTranslator will vary at runtime depending on which JPA implementation is in use, the exception translation aspect provided by Roo should allow the injection of a PersistenceExceptionTranslator by Spring and use that if present. It should gracefully fallback to the present static EntityManagerFactoryUtils approach if the PersistenceExceptionTranslator has not been injected. A possible implementation example has been provided in the
In the meantime users can easily edit the Roo-provided exception translation aspect and delegate to their preferred PersistenceExceptionTranslator. It is also noted that only Hibernate's JPA dialect provides custom translation logic (the OpenJPA and EclipseLink implementations both inherit generic behaviour from DefaultJpaDialect, with DefaultJpaDialect simply delegating to the static EntityManagerFactoryUtils method). Accordingly OpenJPA and EclipseLink users will not obtain any immediate benefit from this enhancement, despite it clearly being beneficial in the long-term when such custom translation logic is provided by those DefaultJpaDialect subclasses.