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