camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Boris Terzic (JIRA)" <j...@apache.org>
Subject [jira] Created: (CAMEL-3353) camel-cxf's CxfRsInvoker silently swallows exceptions
Date Mon, 22 Nov 2010 19:25:24 GMT
camel-cxf's CxfRsInvoker silently swallows exceptions
-----------------------------------------------------

                 Key: CAMEL-3353
                 URL: https://issues.apache.org/activemq/browse/CAMEL-3353
             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.


Mime
View raw message