exposing Exception set in Camel DefaultExchange ?

[jbride]

Hi,

  i'm wondering what needs to be configured in switchyard such that Exceptions set in org.apache.camel.impl.DefaultExchange are ultimately logged to the server.log ?

i've come across a scenario where i can see (only by stepping through the sy code) that a  HandlerException is being correctly thrown at line 98 of org.switchyard.handlers.TransformHandler.

  subsequently, org.apache.camel.util.AsyncProcessorConverterHelper is catching this exception at line 64 and invoking the setException(e) function on the camel DefualtExchange.

  all of that seems great except that this HandlerException is ultimately lost in the sauce somewhere with no trace of it (ie:  nothing at all is logged )

  what the end-user experiences is a time-out (after 15 seconds) waiting for a response from the target service with no indication of the root cause.

  i'm running the latest sy from hudson (build #627).

thanks!  jeff

[kcbabo]

This shouldn't happen.  The routes we define internally include an exception handler specific to HandlerException (heh, that sounds weird).  If a HandlerException is thrown in a route, the exception should be "caught" in the route and channeled into a SY fault.  Do you have a basic app we can use to reproduce this?

[jbride]

yes.  i'm able to reproduce this using the transform-jaxb quickstart with one modification to transform-jaxb/src/main/resources/META-INF/switchyard.xml :

14             from="java:org.switchyard.quickstarts.transform.jaxb.OrderAck" 
 15             to="{rn:switchyard-quickstart:transform-jaxb:1.0}orderAck" 
 16             contextPath="org.switchyard.quickstarts.transform.jaxb"/>

notice the removal of the beginning 'u' in the namespace of the "to" path.

hope this helps.   jeff

[kcbabo]

Ah, so that adds a bit more context.  This is happening on the return path and there may be a hole in our exception handling with the return route.  More to follow ...

[splatch]

This issue was really missed in 0.6. Camel Exchange Bus was able to handle HandlerException and in general did not expect any other exceptions. When RuntimeException was thrown from handler then it was breaking the chain with to handle. Linked issue contains pull request which catches all exceptions, ie. if RuntimeException is thrown then whole exchange is marked as fault.