[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openejb-user
Subject:    Re: Catching OpenJPA validation exceptions in OpenEJB
From:       Dain Sundstrom <dain () iq80 ! com>
Date:       2008-12-29 18:38:57
Message-ID: 8B03D872-3FEA-4C60-A803-F117B6A026A1 () iq80 ! com
[Download RAW message or body]

On Dec 28, 2008, at 8:28 PM, David Blevins wrote:

> On Dec 23, 2008, at 8:06 AM, Luis Fernando Planella Gonzalez wrote:
>
>> Hi all!
>>
>> I'm using OpenEJB 3.1 under Tomcat.
>> When I try to persist an invalid entity, say, with a field  
>> annotated with @Basic(optional=false) with a null value, all I get  
>> is a javax.ejb.EJBTransactionRolledbackException.
>>
>> After a couple of hours in debug, I've noticed the cause in  
>> <tomcat_home>/logs/transaction.log:
>> org.apache.openjpa.persistence.InvalidStateException: The field  
>> "creationDate" of instance "Member#<null>" contained a null value;  
>> the metadata for this field specifies that nulls are illegal.
>>
>> How can I catch such exceptions in order to display an user- 
>> friendly message?
>
> Not sure I have any good ideas.  If I recall correctly, the  
> exception is thrown by the transaction manager doesn't contain this  
> information therefore we are unable to throw it to you as the nested  
> cause of EJBTransactionRolledbackException.
>
> Very recently another user, Geoff Callender, requested the same  
> thing:  https://issues.apache.org/jira/browse/OPENEJB-782
>
> I'm not too familiar with the Geronimo transaction manager (which is  
> the one we use).  Dain or David, either of you have any thoughts on  
> this?
>
> Note in that JIRA issue Geoff suggests a clever workaround which is  
> to call entityManager.flush() in a try/catch block, which will allow  
> you to explicitly catch the InvalidStateException.  Though I agree  
> with Geoff that ideally this would be propagated with the  
> EJBTransactionRolledbackException.

IIRC, the exception from the transaction manager does contain the root  
cause.  Assuming this is true, then OpenEJB is dropping the true root  
cause.  If my assumption is false, we'll need to patch the transaction  
manager.

The full stack trace of the actual thrown exception and the logged  
exception would really help us determine which code to start looking at.

-dain
[prev in list] [next in list] [prev in thread] [next in thread]