cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Parwiz Rezai (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CXF-4496) find of ResponseExceptionMapper do not handle runtime exceptions
Date Sat, 23 Mar 2013 08:01:18 GMT

    [ 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

Mime
View raw message