Mailing-List: contact dev-help@aries.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@aries.apache.org
Date: Wed, 23 Sep 2015 09:04:04 +0000 (UTC)
From: "Christian Schneider (JIRA)" <jira@apache.org>
To: dev@aries.apache.org
Message-ID: <JIRA.12895450.1442928639000.48226.1442999044258@Atlassian.JIRA>
In-Reply-To: <JIRA.12895450.1442928639000@Atlassian.JIRA>
References: <JIRA.12895450.1442928639000@Atlassian.JIRA>
 <JIRA.12895450.1442928639009@arcas>
Subject: [jira] [Resolved] (ARIES-1415) Exception laundering in JpaTemplate
 impls
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/ARIES-1415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christian Schneider resolved ARIES-1415.
----------------------------------------
       Resolution: Fixed
    Fix Version/s: jpa-2.2.0

> Exception laundering in JpaTemplate impls
> -----------------------------------------
>
>                 Key: ARIES-1415
>                 URL: https://issues.apache.org/jira/browse/ARIES-1415
>             Project: Aries
>          Issue Type: Improvement
>          Components: JPA
>    Affects Versions: jpa-2.1.0
>            Reporter: Matthew Pitts
>            Assignee: Christian Schneider
>             Fix For: jpa-2.2.0
>
>
> Currently XaJpaTemplate and ResourceLocalJpaTemplate wrap all caught exceptions in a  new RuntimeException and throw that instead of the original. This can make it problematic to integrate with code that wants to run txExpr methods and catch specific exceptions - like NoResultException or other type of recoverable exception.
> Perhaps a method (like launderTxException) could be added to their base class - AbstractJpaTemplate - which could allow for additional exception laundering.
> Specifically, I'm thinking of something that would actually attempt to instantiate a new instance of the original exception type via reflection and populate it with the necessary detail message. If it is unable to instantiate the original exception, then it can simply rethrow it as-is or maintain the original behavior of wrapping it in a RuntimeException.
> Something like this:
> {code}
>     protected RuntimeException launderTxException(Throwable original, String message) {
>         if (RuntimeException.class.isInstance(original)) {
>             return wrapTxException(RuntimeException.class.cast(original), message);
>         }
>         else {
>             return new RuntimeException(message, original);
>         }
>     }
>     protected RuntimeException wrapTxException(RuntimeException original, String message) {
>         if (message == null)
>             return original;
>         try {
>             RuntimeException wrapper = original.getClass().getConstructor(new Class[]
>             { String.class }).newInstance(message);
>             wrapper.initCause(original);
>             return wrapper;
>         }
>         catch (ReflectiveOperationException e) {
>             return original;
>         }
>     }
> {code}
> Thoughts, comments, criticisms?


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)