cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: cxf rest client always picks the first ResponseExceptionMapper for a method with different exception throws
Date Tue, 26 Mar 2013 08:08:39 GMT
Hi
On 26/03/13 11:00, wizpar@yahoo.com wrote:
> thanks Guys. I will create a patch to submit for this.
Can you provide it today at the latest ? If yes then I can wait.
I was having a patch pending yesterday morning but without a test.
May be I can merge that and you can work on a test ?

If you prefer to do the complete patch then I'll be happy to wait but I 
guess that need to be done pretty soon

Let me know what you prefer
Sergey

>
>
> ________________________________
>   From: Andrei Shakirin<ashakirin@talend.com>
> To: "users@cxf.apache.org"<users@cxf.apache.org>
> Cc: parwiz<wizpar@yahoo.com>
> Sent: Monday, March 25, 2013 1:50 AM
> Subject: RE: cxf rest client always picks the first ResponseExceptionMapper for a method
with different exception throws
>
> Hi,
>
> Thanks Sergei, agree with your proposal.
> @Parwiz: would you like to submit patch yourself? (alternatively I can do it)
>
> Regards,
> Andrei.
>
>
>> -----Original Message-----
>> From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
>> Sent: Sonntag, 24. März 2013 20:14
>> To: users@cxf.apache.org
>> Subject: Re: cxf rest client always picks the first ResponseExceptionMapper
>> for a method with different exception throws
>>
>> Hi
>> On 24/03/13 18:25, Andrei Shakirin wrote:
>>> Hi,
>>>
>>> Currently ClientProxyImpl selects exactly one response exception mapper.
>> Selection is based on exceptions declared in business method and generic
>> parameter of response exception mapper
>> (ClientProxyImpl.findExceptionMapper(), ClientProviderFactory.
>> createResponseExceptionMapper(), ProviderFactory.handleMapper()).
>>> Chain of response exception mappers is not supported.
>>>
>> Indeed. One uses a response exception mapper to map a given Response to
>> the exception, and as far as the runtime is concerned, it does not know
>> which (negative) Response may correspond to which declared Exception
>> class.
>>> Not sure how many use cases require multiple response exception
>> mappers for single method, but basically it can be supported as well.
>>>
>> You are right, if a given mapper returns 'null', then, the runtime can
>> check if another Throwable is available, if yes - it will try to find
>> another mapper for the next declared Exception
>>
>> So if we have
>>
>> public get() throws ExceptionA, ExceptionB {
>> }
>>
>> and both RuntimeExceptionAMapper and RuntimeExceptionBMapper are
>> available, then if either of them (depending on which one is selected
>> first) returns null (example, it recognizes that the response status and
>> headers do not 'represent' a given exception), then the next mapper for
>> the next Throwable can be tried.
>>
>> We might have a case where we have
>> RuntimeExceptionMapper<RuntimeException>  which may return 'null' for
>> ExceptionA, so it will be retried again for ExceptionB, but that is
>> probably a very rare case and not really a big issue IMHO.
>>
>>
>> Thanks, Sergey
>>
>>> Regards,
>>> Andrei.
>>>
>>>> -----Original Message-----
>>>> From: parwiz [mailto:wizpar@yahoo.com]
>>>> Sent: Samstag, 23. März 2013 09:21
>>>> To: users@cxf.apache.org
>>>> Subject: Re: cxf rest client always picks the first
>> ResponseExceptionMapper
>>>> for a method with different exception throws
>>>>
>>>> maybe perhaps add a header in response when a fault occurs and have
>> the
>>>> fully qualified name of the exception in there.. and then in our client side
>>>> findExceptionMapper we can first use this header and see if a mapper
>> exists
>>>> for it or a super class of it..
>>>> if yes use that else fall back on the current method of going by
>>>> Method.getExceptionTypes()?
>>>>
>>>> please let me know because right now this is cause us some issues..
>>>>
>>>> and no I can't simply extend both Exception1 and Exception2 from same
>>>> parent and handle them that way... one is a legacy exception (external
>>>> source/3rd
>>>> party) and one is a newer exception from our own code
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context: http://cxf.547215.n5.nabble.com/cxf-rest-
>>>> client-always-picks-the-first-ResponseExceptionMapper-for-a-method-
>> with-
>>>> different-exceptions-tp5725071p5725072.html
>>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>



Mime
View raw message