Page History

...

Here if the processing of seda:inputA or seda:inputB cause a ValidationException to be thrown (such as due to the XSD validation of the Validator Validation component or the Relax NG Compact syntax validation of the Jing component), then the message will be sent to activemq:validationFailed queue.

...

Using onException to handle known exceptions is a very powerful feature in Camel. However prior to Camel 1.5 you could not mark the exception as being handled, so the caller would still receive the caused exception as a response. In Camel 1.5 you can now change this behaviour behavior with the new handle DSL. The handle is a Predicate that is overloaded to accept three types of parameters:

• Boolean
• Predicate
• Expression that will be evaluates as a Predicate using this rulesetrule set: If the expressions returns a Boolean its used directly. For any other response its regarded as true if the response is not null.

For instance to mark all ValidationException as being handled we can do this:

...

{snippet:id=e3|lang=java|url=activemq/camel/trunk/camel-core/src/test/java/org/apache/camel/processor/DeadLetterChannelHandledExampleTest.java}

So what happens?

If we sent an order that is being processed OK then the caller will receive an Exchange as reply containing Order OK and as the payload and the order id 123 as orderid=123 in a header.

If the order could not be processed and thus an OrderFailedException was thrown the caller will not receive this exception (as opposed to in Camel 1.4, where the caller received the OrderFailedException) but our customized response that we have fabricated in the orderFailed method in our OrderService. So the caller receives an Exchange with the payload Order ERROR and a header with orderid=failed in a header.

Overloading the RedeliveryPolicy

...