[
https://issues.apache.org/jira/browse/CXF-4496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13611644#comment-13611644
]
Parwiz Rezai edited comment on CXF-4496 at 3/23/13 7:59 AM:
------------------------------------------------------------
actually the bigger issue is that it always picks the first exception mapper
based on method signature.
https://issues.apache.org/jira/browse/CXF-4912
what's happening right now is if you say have two different exception in your
throws method
myMethod() throws Exception2, Exception1;
and mappers for both of those exceptions on server side and client side (maybe
you are doing different
things.. so yes i know you can have one super class if they are both checked
exceptions.. let's say
you have a legacy exception and you don't have source for it.. and a new
exception you created for something else)
now the client code is blind and picks the first mapper when a fault occurs so
in this it will always
default to Exception2ResponeMapper on client side.. even if in the method you
happen to throw Exception1
this is incorrect..
please take a look again as this is a big issue if you have multiple mappers
and a method that
throws more than one exception in its signature (be it checked or runtime or
multiple checked exceptions)...
it will pick the first mapper for the first exception listed after throws
keyword.. not
actually match based on actual exception type and mappers available.
maybe allow the response to have a header of some sort that contains the
exception name/class
and in the findExceptionMapper() use that header to know exactly what exception
occurred and go
find a mapper based on that type instead of picking the first exception after
the throws clause
aka Class<?>[] exTypes = m.getExceptionTypes(); <-- the mapper is
selected based on the order returned by this
was (Author: parwiz):
actually the bigger issue is that it always picks the first exception
mapper based on method signature.
https://issues.apache.org/jira/browse/CXF-4912
what's happening right now is if you say have two different exception in your
throws method
myMethod() throws Exception2, Exception1;
and mappers for both of those exceptions on server side and client side (maybe
you are doing different
things.. so yes i know you can have one super class if they are both checked
exceptions.. let's say
you have a legacy exception and you don't have source for it.. and a new
exception you created for something else)
now the client code is blind and picks the first mapper when a fault occurs so
in this it will always
default to Exception2ResponeMapper on client side.. even if in the method you
happen to throw Exception1
this is incorrect..
please take a look again as this is a big issue if you have multiple mappers
and a method that
throws more than one exception in its signature (be it checked or runtime or
multiple checked exceptions)...
it will pick the first mapper for the first exception listed after throws
keyword.. not
actually match based on actual exception type and mappers available.
> find of ResponseExceptionMapper do not handle runtime exceptions
> ----------------------------------------------------------------
>
> Key: CXF-4496
> URL: https://issues.apache.org/jira/browse/CXF-4496
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 2.6.2
> Reporter: n0rad
> Assignee: Sergey Beryozkin
> Priority: Minor
> Fix For: 2.6.3, 2.7.0
>
>
> In org.apache.cxf.jaxrs.client.ClientProxyImpl.findExceptionMapper(Method,
> Message)
> The responseExceptionMapper is selected based on exception defined in the
> resource method signature but this method may have thrown a RuntimeException :
> {code:java}
> @Path("/")
> public interface RestMcuBoardResource {
> @GET
> public RestMcuBoard getBoard();
> }
> {code}
> does not work where this one work
> {code:java}
> @Path("/")
> public interface RestMcuBoardResource {
> @GET
> public RestMcuBoard getBoard() throws runtimeException;
> }
> {code}
> a fix could be :
> {code:java}
> private static ResponseExceptionMapper<?> findExceptionMapper(Method m,
> Message message) {
> ProviderFactory pf = ProviderFactory.getInstance(message);
> for (Class<?> exType : m.getExceptionTypes()) {
> ResponseExceptionMapper<?> mapper =
> pf.createResponseExceptionMapper(exType);
> if (mapper != null) {
> return mapper;
> }
> }
> + return pf.createResponseExceptionMapper(RuntimeException.class);
> - return null;
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
