Thanks everybody for help so far. The scenario I described previously was
implemented just by throwing the exceptions from corresponding validator
Java beans at step 2 and 3. It seems that Camel wraps that exception and
sends it to the web service client without any additional code.
There is one downside: the logs contain the exception stack trace although
this is some sort of expected business exception and from this point of view
should be treated as expected execution scenario. If I call
setBody(exception) inside some of the validator beans, the Jaxb marshaller
complains that the exception class is not known to the context.
The Camel related question would be: how Camel does that magic of properly
sending the web service exception to the client when it is thrown inside the
validation bean, since it obviously doesn't set it as the body of the in/out
message? Could I somehow do this myself inside the validation bean so as to
avoid the exception being logged?
By the way this code:
<onException>
<exception>order.InvalidRequest</exception>
<handled>
<constant>true</constant>
</handled>
<setBody>
<simple>${exception}</simple>
</setBody>
<stop/>
</onException>
causes the same Jaxb marshaller exception to the thrown...
--
View this message in context:
http://camel.465427.n5.nabble.com/Understanding-Request-Reply-EIP-in-Spring-DSL-tp5662809p5670749.html
Sent from the Camel - Users mailing list archive at Nabble.com.
