Re: cxf rest client always picks the first ResponseExceptionMapper for a method with different exception throws

Tue, 26 Mar 2013 01:09:11 -0700 

Hi
On 26/03/13 11:00, [email protected] 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<[email protected]>
To: "[email protected]"<[email protected]>
Cc: parwiz<[email protected]>
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:[email protected]]
Sent: Sonntag, 24. März 2013 20:14
To: [email protected]
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:[email protected]]
Sent: Samstag, 23. März 2013 09:21
To: [email protected]
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.

Reply via email to