> IMHO we should not introduce a custom protocol into the process of > selecting the exception mapper on the client side. I think if we a case when > at least 2 unrelated exception classes are declared and related mappers are > available then a proper mapper must analyze the provided Response and > decide whether to map it to a known exception or not
+1 from me. Regards, Andrei. > -----Original Message----- > From: Sergey Beryozkin [mailto:[email protected]] > Sent: Dienstag, 26. März 2013 13:36 > To: [email protected] > Subject: Re: cxf rest client always picks the first ResponseExceptionMapper > for a method with different exception throws > > Hi > On 26/03/13 11:32, [email protected] wrote: > > > > 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. > > > Thanks for your effort, I've applied a patch with the very minor modifications > plus I've added a test. > > 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. > > > IMHO we should not introduce a custom protocol into the process of > selecting the exception mapper on the client side. I think if we a case when > at least 2 unrelated exception classes are declared and related mappers are > available then a proper mapper must analyze the provided Response and > decide whether to map it to a known exception or not > > Thanks, Sergey > > > > > 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] <mailto:[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] > > <mailto:[email protected]>> > To: "[email protected] > > <mailto:[email protected]>"<[email protected] > > <mailto:[email protected]>> > > > Cc: parwiz<[email protected] <mailto:[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] > > <mailto:[email protected]>] >> Sent: Sonntag, 24. März 2013 20:14 > > >> To: [email protected] <mailto:[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] > <mailto:[email protected]>] > > >>>> Sent: Samstag, 23. März 2013 09:21 >>>> To: [email protected] > > <mailto:[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 > > <http://nabble.com/>. > > >> > > > > > > > > > > > -- > Sergey Beryozkin > > Talend Community Coders > http://coders.talend.com/ > > Blog: http://sberyozkin.blogspot.com
