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.