Hi,
I attache this to the jira issue as well but here it is again https://issues.apache.org/jira/browse/CXF-4912 basically I went with your idea of trying the next response mapper if the first one ends up returning null. please review and let me know if anything is not right. I would like to also propose a patch for my other option where we let the user use a specific mapper based on their exception class they specify so in their server mapper they can add a header like Response.header("exceptionClass", exception.getClass().getCanonicalName()).build(); and in our checkResponse before we loop and find throws and look for exception mappers we can do something like String className = response.getHeaders().getFirst("exceptionClass"); if not null Class exType = Class.forName(className); if we can find a findExceptionMapper(m, inMessage, exType); based on that specific user specified exception then go ahead use it else fall back on the old method of looping through throws clause.. i think this is a good way to allow user control if they want to add this header in their mapper on server side then it lets them be more confident that their specific mapper will get picked on front side too. but i haven't added this to the patch.. i have the code working but i wanted to wait on what you think. the other part is done per discussions below :) thanks guys, parwiz ________________________________ From: Sergey Beryozkin <[email protected]> To: [email protected] Sent: Tuesday, March 26, 2013 1:08 AM Subject: Re: cxf rest client always picks the first ResponseExceptionMapper for a method with different exception throws 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. >>
