camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Boris Terzic (JIRA)" <>
Subject [jira] Updated: (CAMEL-3353) CxfRsInvoker silently swallows exceptions
Date Mon, 22 Nov 2010 19:27:24 GMT


Boris Terzic updated CAMEL-3353:

    Summary: CxfRsInvoker silently swallows exceptions  (was: camel-cxf's CxfRsInvoker silently
swallows exceptions)

> CxfRsInvoker silently swallows exceptions
> -----------------------------------------
>                 Key: CAMEL-3353
>                 URL:
>             Project: Apache Camel
>          Issue Type: Bug
>          Components: camel-cxf
>    Affects Versions: 2.5.0
>            Reporter: Boris Terzic
> 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.

View raw message