Spring Framework
  1. Spring Framework
  2. SPR-6282

Enhance JPA Exception Translation to use PersistenceExceptionTranslator injected instance

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Core:AOP
    • Labels:
      None
    • Last commented by a User:
      false

      Description

      (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:

      public interface PersistenceExceptionTranslator {
      	DataAccessException translateExceptionIfPossible(RuntimeException ex);
      
      }
      

      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 ROO-182 comments.

      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.

        Issue Links

          Activity

          Hide
          Rossen Stoyanchev added a comment -

          This issue has been resolved through a selective bulk update, as part of a larger effort to better manage unresolved issues. To qualify for the update, the issue was either created before Spring 3.0 or affects a version older than Spring 3.0 and is not a bug.

          There is a good chance the request was made obsolete, or at least partly outdated, by changes in later versions of Spring including deprecations. It is also possible it didn't get enough traction or we didn't have enough time to address it. One way or another, we didn't get to it.

          If you believe the issue, or some aspects of it, are still relevant and worth pursuing at present you may re-open this issue or create a new one with a more up-to-date description.

          We thank you for your contributions and encourage you to become familiar with the current process of managing Spring Framework JIRA issues that has been in use for over a year.

          Show
          Rossen Stoyanchev added a comment - This issue has been resolved through a selective bulk update, as part of a larger effort to better manage unresolved issues. To qualify for the update, the issue was either created before Spring 3.0 or affects a version older than Spring 3.0 and is not a bug. There is a good chance the request was made obsolete, or at least partly outdated, by changes in later versions of Spring including deprecations. It is also possible it didn't get enough traction or we didn't have enough time to address it. One way or another, we didn't get to it. If you believe the issue, or some aspects of it, are still relevant and worth pursuing at present you may re-open this issue or create a new one with a more up-to-date description. We thank you for your contributions and encourage you to become familiar with the current process of managing Spring Framework JIRA issues that has been in use for over a year.

            People

            • Assignee:
              Ramnivas Laddad
              Reporter:
              Jukka Palomäki
              Last updater:
              Trevor Marshall
            • Votes:
              2 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Days since last comment:
                1 year, 44 weeks, 2 days ago