aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Valentin Mahrwald <>
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, 01 Apr 2010 10:57:24 GMT
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  
could actually have been thrown by the intercepted method. With the  
current design of Collaborator though, it could have been a checked  
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.


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
> <> 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?

View raw message