thanks Guys. I will create a patch to submit for this.
________________________________ 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. >
