[jira] Commented: (CAMEL-3353) CxfRsInvoker silently swallows exceptions

["Willem Jiang (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CAMEL-3353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12975215#action_12975215 ] 

Willem Jiang commented on CAMEL-3353:
-------------------------------------

@Boris
I just committed a fix of this issue, now the exception will be sent back to the client.
Please check out the latest Camel 2.6-SNAPSHOT to verify the fix.

> CxfRsInvoker silently swallows exceptions
> -----------------------------------------
>
>                 Key: CAMEL-3353
>                 URL: https://issues.apache.org/jira/browse/CAMEL-3353
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-cxf
>    Affects Versions: 2.5.0
>            Reporter: Boris Terzic
>            Assignee: Willem Jiang
>             Fix For: 2.6.0
>
>
> If you have a route with a CXF consuming endpoint in the beginning and any component afterwards that can produce Exceptions that are not RuntimeCamelExceptions or WebApplicationException then the CxfRsInvoker will swallow the exception and return a HTTP 204 (all fine but no content to return) response.
> For example in the following route:
> {code:java}
>  from("cxfrs://bean://fooServer")
>             .convertBodyTo(Foo.class)
>             .to("bean-validator://x")
>             .to("jms:queue:foos").inOnly();
> {code}
> The bean validator component can throw BeanValidationException when the Foo instance has errors. This exception will be ignored by the CxfRsInvoker.
> This causes important exceptions to become invisible by default which seems wrong to me. The docs and Camel in Action additionally talk about how the DefaultErrorHandler has a strategy of returning exceptions to the caller and this is also not happening here.
> My local fix is a patched version of camel-cxf that converts any unknown exception (i.e. not CamelRuntimeException or WebApplicationException) to a WebApplicationException with the original exception as a constructor parameter. This is then effectively an HTTP 500 Exception and will be returned as such to the caller.
> However my knowledge of camel and camel-cxf is not sufficient to ascertain whether this is the right approach, it seems to me that the CamelRuntimeException should also be treated this way since in the current code that will also be swallowed (as far as I can tell).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.