cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From wiz...@yahoo.com
Subject Re: cxf rest client always picks the first ResponseExceptionMapper for a method with different exception throws
Date Tue, 26 Mar 2013 08:00:50 GMT
thanks Guys. I will create a patch to submit for this.


________________________________
 From: Andrei Shakirin <ashakirin@talend.com>
To: "users@cxf.apache.org" <users@cxf.apache.org> 
Cc: parwiz <wizpar@yahoo.com> 
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:sberyozkin@gmail.com]
> Sent: Sonntag, 24. März 2013 20:14
> To: users@cxf.apache.org
> 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:wizpar@yahoo.com]
> >> Sent: Samstag, 23. März 2013 09:21
> >> To: users@cxf.apache.org
> >> 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.
> 
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message