tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karsten Ohme <widerst...@t-online.de>
Subject Re: AW: @ApplicationException(rollback=true) ignored from external API
Date Sat, 28 Jun 2008 00:04:05 GMT
David Blevins schrieb:
> I think there was something with the binaries I published.  Had to clean 
> out all the old snapshots and redeploy to a clean repo before I could 
> get the updates to come down.
> 
> Try it again. (clean out the openejb section of your repo for good 
> measure).

Well at the moment I cannot get 
org.apache.openejb:xbean-finder:jar:3.4-r636443-SNAPSHOT form the repo. 
I will try it again tomorrow.

Regards,
Karsten
> 
> -David
> 
> 
> On Jun 27, 2008, at 8:45 AM, <Karsten.Ohme@t-systems.com> 
> <Karsten.Ohme@t-systems.com> wrote:
> 
>>
>> No, does not work. See the attached sample project.
>>
>> In the API is the annotated ServiceAddressException class. But the 
>> unit tests fails.
>>
>> Regards,
>> Karsten
>>
>>
>>> -----Urspr√ľngliche Nachricht-----
>>> Von: David Blevins [mailto:david.blevins@visi.com]
>>> Gesendet: Freitag, 27. Juni 2008 07:32
>>> An: users@openejb.apache.org
>>> Betreff: Re: @ApplicationException(rollback=true) ignored
>>> from external API
>>>
>>>
>>> On Jun 25, 2008, at 4:42 PM, Karsten Ohme wrote:
>>>
>>>> David Blevins schrieb:
>>>>> On Jun 25, 2008, at 9:38 AM, <Karsten.Ohme@t-systems.com>
>>>>> <Karsten.Ohme@t-systems.com
>>>>>> wrote:
>>>>>> I run a test which provokes an application exception. The
>>> exception
>>>>>> is defined in the same module and annotated with
>>>>>> @ApplicationException(rollback=true). The Exception is
>>> rolled back.
>>>>>> Fine.
>>>>>>
>>>>>> Another test checks also an exception. The exception is
>>> not from an
>>>>>> EJB module, but from an imported API. The exception has the same
>>>>>> annotation, but the transaction is not rolled back. It
>>> seams to me
>>>>>> that the annotation in this class is ignored.
>>>>> We definitely don't check the annotations at runtime,
>>> simply because
>>>>> you can override them via the deployment descriptor so the
>>> "merged"
>>>>> set of meta data is the only safe thing to execute against
>>> at runtime
>>>>> (not if we expect to pass the tck anyway ;).  But as you
>>> point out we
>>>>> just check the module itself for @ApplicationException annotated
>>>>> classes.
>>>>
>>>> I don't have them annotated in the deployment descriptor.
>>> This would
>>>> be very uncomfortable, because each module which uses the exception
>>>> from the other module would have to do this.
>>>
>>> Agree, that would be an unnecessary pain.
>>>
>>>>> Hmm...
>>>>> Is the annotated exception class listed in any of the
>>> throws clauses
>>>>> of the business interface methods in module B?
>>>
>>>> Yes, it is.
>>>>
>>>>> (where module A has the exception class, module B does
>>> not) If so, we
>>>>> could expand our support to looking there too in addition
>>> to scraping
>>>>> the module jar.
>>>>
>>>> Would be nice.
>>>
>>> Ok. Implemented that technique.  Should you decide to
>>> override the app exception in the deployment descriptor of
>>> module B, for example, that will work too.
>>>
>>> New 3.1-SNAPSHOT binaries have been published.  Give it a try
>>> and let us know if it works out.
>>>
>>> -David
>>>
>>>
>> <applicationexceptiontest.zip>
> 
> 
> 


Mime
View raw message