You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by parwiz <wi...@yahoo.com> on 2013/03/23 09:13:15 UTC
cxf rest client always picks the first ResponseExceptionMapper for
a method with different exception throws
Hi,
I created a jira issue for this but perhaps i'm wrong and should've posted
here first so i apologize for that.
the issue i'm seeing is that the current findExceptionMapper in
ClientProxyImpl
seems to go by getting the exceptions in the throws signature of the method
and once it
finds a mapper for the first Exception listed it will use this
even if the exceptions don't match
so say i have
myMethod() throws Exception1, Exception2;
with corresponding server/client exception to response and from mappers.
now in the method i throw Exception2
based on the current findExceptionMapper it will pick up the response mapper
for
Exception1 on client side even if i have a Exception2ResponseMapper also
registered and want to use that..
reordering them will pick the right one for just that situation but suppose
we throw Exception1 in there in some other branch of the method.. now it
picks Exception2ResponseMapper if
our signature is
myMethod() throws Exception2, Exception1;
is there a workaround for this?
the jira issue is here with deails of my classes and even a zip file with
full setup
of mappers/exception and server/client test:
https://issues.apache.org/jira/browse/CXF-4912
--
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-tp5725071.html
Sent from the cxf-user mailing list archive at Nabble.com.
RE: cxf rest client always picks the first ResponseExceptionMapper
for a method with different exception throws
Posted by Andrei Shakirin <as...@talend.com>.
Thanks for warm words.
If you will stay active in JIRA by applying patches and in mailing list - it is a good chance to become CXF committer.
Cheers,
Andrei.
> -----Original Message-----
> From: parwiz [mailto:wizpar@yahoo.com]
> Sent: Dienstag, 26. März 2013 17:46
> To: users@cxf.apache.org
> Subject: RE: cxf rest client always picks the first ResponseExceptionMapper
> for a method with different exception throws
>
> Okay sounds good guys.. thanks for the pointers and help.
>
> at least got the multiple mapper portion in there :)
>
> This is great I'm going to help out here on the mailing list and more patches in
> future for cxf during my free time. CXF has been great for us and it's been
> very solid.. thanks for all the hard work.
>
>
>
>
>
>
> --
> 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-tp5725071p5725307.html
> Sent from the cxf-user mailing list archive at Nabble.com.
RE: cxf rest client always picks the first ResponseExceptionMapper
for a method with different exception throws
Posted by parwiz <wi...@yahoo.com>.
Okay sounds good guys.. thanks for the pointers and help.
at least got the multiple mapper portion in there :)
This is great I'm going to help out here on the mailing list and more
patches in future for cxf during my free time. CXF has been great for us and
it's been very solid.. thanks for all the hard work.
--
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-tp5725071p5725307.html
Sent from the cxf-user mailing list archive at Nabble.com.
RE: cxf rest client always picks the first ResponseExceptionMapper
for a method with different exception throws
Posted by Andrei Shakirin <as...@talend.com>.
> 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:sberyozkin@gmail.com]
> Sent: Dienstag, 26. März 2013 13:36
> To: users@cxf.apache.org
> Subject: Re: cxf rest client always picks the first ResponseExceptionMapper
> for a method with different exception throws
>
> Hi
> On 26/03/13 11:32, wizpar@yahoo.com 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 <sb...@gmail.com>
> > *To:* users@cxf.apache.org
> > *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, wizpar@yahoo.com <ma...@yahoo.com>
> 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<ashakirin@talend.com
> > <ma...@talend.com>> > To: "users@cxf.apache.org
> > <ma...@cxf.apache.org>"<users@cxf.apache.org
> > <ma...@cxf.apache.org>>
> > > Cc: parwiz<wizpar@yahoo.com <ma...@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
> > <ma...@gmail.com>] >> Sent: Sonntag, 24. März 2013 20:14
> > >> To: users@cxf.apache.org <ma...@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
> <ma...@yahoo.com>]
> > >>>> Sent: Samstag, 23. März 2013 09:21 >>>> To: users@cxf.apache.org
> > <ma...@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
> > <http://nabble.com/>.
> > >>
> >
> >
> >
> >
>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
>
> Blog: http://sberyozkin.blogspot.com
Re: cxf rest client always picks the first ResponseExceptionMapper
for a method with different exception throws
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
On 26/03/13 11:32, wizpar@yahoo.com 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 <sb...@gmail.com>
> *To:* users@cxf.apache.org
> *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, wizpar@yahoo.com <ma...@yahoo.com> 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<ashakirin@talend.com <ma...@talend.com>>
> > To: "users@cxf.apache.org
> <ma...@cxf.apache.org>"<users@cxf.apache.org
> <ma...@cxf.apache.org>>
> > Cc: parwiz<wizpar@yahoo.com <ma...@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
> <ma...@gmail.com>]
> >> Sent: Sonntag, 24. März 2013 20:14
> >> To: users@cxf.apache.org <ma...@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 <ma...@yahoo.com>]
> >>>> Sent: Samstag, 23. März 2013 09:21
> >>>> To: users@cxf.apache.org <ma...@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
> <http://nabble.com/>.
> >>
>
>
>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: cxf rest client always picks the first ResponseExceptionMapper for a method with different exception throws
Posted by wi...@yahoo.com.
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 <sb...@gmail.com>
To: users@cxf.apache.org
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, wizpar@yahoo.com 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<as...@talend.com>
> To: "users@cxf.apache.org"<us...@cxf.apache.org>
> Cc: parwiz<wi...@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.
>>
Re: cxf rest client always picks the first ResponseExceptionMapper
for a method with different exception throws
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
On 26/03/13 11:00, wizpar@yahoo.com 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<as...@talend.com>
> To: "users@cxf.apache.org"<us...@cxf.apache.org>
> Cc: parwiz<wi...@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.
>>
Re: cxf rest client always picks the first ResponseExceptionMapper for a method with different exception throws
Posted by wi...@yahoo.com.
thanks Guys. I will create a patch to submit for this.
________________________________
From: Andrei Shakirin <as...@talend.com>
To: "users@cxf.apache.org" <us...@cxf.apache.org>
Cc: parwiz <wi...@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.
>
RE: cxf rest client always picks the first ResponseExceptionMapper
for a method with different exception throws
Posted by Andrei Shakirin <as...@talend.com>.
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.
>
Re: cxf rest client always picks the first ResponseExceptionMapper
for a method with different exception throws
Posted by Sergey Beryozkin <sb...@gmail.com>.
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.
RE: cxf rest client always picks the first ResponseExceptionMapper
for a method with different exception throws
Posted by Andrei Shakirin <as...@talend.com>.
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.
Not sure how many use cases require multiple response exception mappers for single method, but basically it can be supported as well.
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.
Re: cxf rest client always picks the first ResponseExceptionMapper
for a method with different exception throws
Posted by parwiz <wi...@yahoo.com>.
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.