Mailing-List: contact aries-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: aries-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of vmahrwald@googlemail.com
 designates 209.85.218.213 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=googlemail.com; s=gamma;
        h=message-id:from:to:in-reply-to:content-type
         :content-transfer-encoding:mime-version:subject:date:references
         :x-mailer;
        b=ri+9ZTs1toMHSXTJXqJkVXSqM5yFU8K0L55hgmtvw/0nD5u3bWRusdW9/aFvu7ZMHD
         GrySSQUjCs9eTKk58ZOVmGgu6EIZxDteSNOobLEkCAN7NIaQL4hNpCtKv1MtuA0OIs9u
         z/FJpyj+JSrF0zlqJBWAQP8FRWOza2bF0Arw4=
Message-Id: <DB3FE19C-E0E8-4A18-83C7-FE5F65402108@gmail.com>
From: Valentin Mahrwald <vmahrwald@googlemail.com>
To: aries-dev@incubator.apache.org
In-Reply-To: <n2yadd18bc81003310617xfbabba15k7325fb722594c85f@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Re: svn commit: r928178 - in /incubator/aries/trunk:
 blueprint/blueprint-core/src/main/java/org/apache/aries/blueprint/
 blueprint/blueprint-core/src/main/java/org/apache/aries/blueprint/proxy/
 blueprint/blueprint-testbundlea/src/main/java/org/apache/
Date: Thu, 1 Apr 2010 11:57:24 +0100
References: <add18bc81003301304i374d1abep152452d6546f834e@mail.gmail.com>
 <8240AF16-496B-4027-8DDB-A68272122661@gmail.com>
 <9BFE3B59-5BE7-4EC0-8AF3-B9253C0E1DCB@york.ac.uk>
 <n2yadd18bc81003310617xfbabba15k7325fb722594c85f@mail.gmail.com>

As discussed yesterday this is a very valid point, the new code is  
only equivalent to the old one if the exception passed into to the  
interceptor
could actually have been thrown by the intercepted method. With the  
current design of Collaborator though, it could have been a checked  
Exception
that was thrown by another interceptor.

This points to a lack in the Blueprint Collaborator implementation. So  
I will raise a bug against that
to make sure checked Exception thrown by interceptors are  
appropriately converted into say UndeclaredThrowableExceptions before  
being passed
to further interceptors.

Valentin

On 31 Mar 2010, at 14:17, Lin Sun wrote:

> Right the runtime exception was already handled before and the new
> code covers it too. :)
>
> I think it is reasonable to say that every exception that is not an
> Error or a RuntimeException is a declared exception, but I am not sure
> if it is a declared application exception.  It may or may not, for
> example it could be an exception like SystemException from the
> transaction manager.  IIUC, the previous code would not consider
> SystemException an application exception and set the rollback only on
> the transaction, while the new code won't.
> Lin
>
> On Wed, Mar 31, 2010 at 2:06 AM, Valentin Mahrwald
> <vmahrwald@googlemail.com> wrote:
>>
>> On 31 Mar 2010, at 06:58, Valentin Mahrwald wrote:
>>
>>> Yes, that is intended :)
>>>
>>> The new logic does the same as the old only a bit more efficient  
>>> in that
>>> every exception that is not an Error or a RuntimeException is a  
>>> declared
>>> exception.
>>>
>>> There is one subtle difference though. A RuntimeException that is  
>>> declared
>>> in the throws clause of a method is still treated as a  
>>> RuntimeException and
>>> not a declared Exception. This is similar to what EJB does and I  
>>> believe
>>> correct for our purposes (Joe Bohn also raised this as a bug  
>>> previously,
>>> ARIES 258).
>>
>> Doh, shouldn't answer emails before breakfast. The RuntimeException  
>> case was
>> already handled before, so the new code should in fact do exactly  
>> the same
>> as the old code (except more efficiently).
>>
>>> Regards,
>>>
>>> Valentin
>>>
>>> On 30 Mar 2010, at 21:04, Lin Sun wrote:
>>>
>>>>
>>>> I noticed that this removed the previous checking of whether the  
>>>> ex is
>>>> one of the method m declared exceptions.  Method m is now not  
>>>> used at
>>>> all in this postCallWithException.  Is that intended?
>>>
>>
>>