Modified: websites/production/camel/content/exception-clause.html
==============================================================================
--- websites/production/camel/content/exception-clause.html (original)
+++ websites/production/camel/content/exception-clause.html Fri Aug 25 08:22:01
2017
@@ -36,17 +36,6 @@
<![endif]-->
- <link href='//camel.apache.org/styles/highlighter/styles/shCoreCamel.css'
rel='stylesheet' type='text/css' />
- <link href='//camel.apache.org/styles/highlighter/styles/shThemeCamel.css'
rel='stylesheet' type='text/css' />
- <script src='//camel.apache.org/styles/highlighter/scripts/shCore.js'
type='text/javascript'></script>
- <script src='//camel.apache.org/styles/highlighter/scripts/shBrushJava.js'
type='text/javascript'></script>
- <script src='//camel.apache.org/styles/highlighter/scripts/shBrushXml.js'
type='text/javascript'></script>
- <script src='//camel.apache.org/styles/highlighter/scripts/shBrushPlain.js'
type='text/javascript'></script>
-
- <script type="text/javascript">
- SyntaxHighlighter.defaults['toolbar'] = false;
- SyntaxHighlighter.all();
- </script>
<title>
Apache Camel: Exception Clause
@@ -86,42 +75,33 @@
<tbody>
<tr>
<td valign="top" width="100%">
-<div class="wiki-content maincontent"><p> </p><h2
id="ExceptionClause-ExceptionClause">Exception Clause</h2><p>You can use the
<em>Exception Clause</em> in the Java <a shape="rect" href="dsl.html">DSL</a>
to specify the error handling you require on a per exception type basis using
the <strong><code>onException()</code></strong> method. To get started we give
quick sample before digging into how it works.</p><p>For example if you want to
perform a specific piece of processing if a certain exception is raised you can
do this simply via:</p><div class="code panel pdl" style="border-width:
1px;"><div class="codeContent panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[onException(ValidationException.class)
- .to("activemq:validationFailed");
+<div class="wiki-content maincontent"><p> </p><h2
id="ExceptionClause-ExceptionClause">Exception Clause</h2><p>You can use the
<em>Exception Clause</em> in the Java <a shape="rect" href="dsl.html">DSL</a>
to specify the error handling you require on a per exception type basis using
the <strong><code>onException()</code></strong> method. To get started we give
quick sample before digging into how it works.</p><p>For example if you want to
perform a specific piece of processing if a certain exception is raised you can
do this simply via:</p><parameter
ac:name="language">java</parameter><plain-text-body>onException(ValidationException.class)
+ .to("activemq:validationFailed");
-from("seda:inputA")
- .to("validation:foo/bar.xsd", "activemq:someQueue");
+from("seda:inputA")
+ .to("validation:foo/bar.xsd", "activemq:someQueue");
-from("seda:inputB")
- .to("direct:foo")
- .to("rnc:mySchema.rnc", "activemq:anotherQueue");
-]]></script>
-</div></div><p>Here if the processing of
<strong><code>seda:inputA</code></strong>
or <strong><code>seda:inputB</code></strong> cause
a <strong><code>ValidationException</code></strong> to be thrown (such as
due to the XSD validation of the <a shape="rect"
href="validation.html">Validation</a> component or the Relax NG Compact syntax
validation of the <a shape="rect" href="jing.html">Jing</a> component), then
the message will be sent to the
<strong><code>activemq:validationFailed</code></strong> queue.</p><p>You can
define multiple <strong><code>onException</code></strong> clauses for
different behavior:</p><div class="code panel pdl" style="border-width:
1px;"><div class="codeContent panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[onException(ValidationException.class)
- .to("activemq:validationFailed");
+from("seda:inputB")
+ .to("direct:foo")
+ .to("rnc:mySchema.rnc", "activemq:anotherQueue");
+</plain-text-body><p>Here if the processing of
<strong><code>seda:inputA</code></strong>
or <strong><code>seda:inputB</code></strong> cause
a <strong><code>ValidationException</code></strong> to be thrown (such as
due to the XSD validation of the <a shape="rect"
href="validation.html">Validation</a> component or the Relax NG Compact syntax
validation of the <a shape="rect" href="jing.html">Jing</a> component), then
the message will be sent to the
<strong><code>activemq:validationFailed</code></strong> queue.</p><p>You can
define multiple <strong><code>onException</code></strong> clauses for
different behavior:</p><parameter
ac:name="">java</parameter><plain-text-body>onException(ValidationException.class)
+ .to("activemq:validationFailed");
onException(ShipOrderException.class)
- .to("activemq:shipFailed");
+ .to("activemq:shipFailed");
-from("seda:order")
- .to("bean:processOrder");
-]]></script>
-</div></div><h3 id="ExceptionClause-Scopes">Scopes</h3><p>Exception clauses is
scoped as either:</p><ul class="alternate"><li>global (for Java DSL that is
per <strong><code>RouteBuilder</code></strong> instances, to reuse, see
note below)</li><li>or route specific</li></ul><p>Where the
<strong>global</strong> are the simplest and most easy to understand. In the
advanced section we dig into the route specific and even combining them.
However</p><p> </p><div class="confluence-information-macro
confluence-information-macro-information"><span class="aui-icon aui-icon-small
aui-iconfont-info confluence-information-macro-icon"></span><div
class="confluence-information-macro-body"><p>Global scope for Java DSL is per
<strong><code>RouteBuilder</code></strong> instance, so if you want to share
among multiple <strong><code>RouteBuilder</code></strong> classes, then create
a base abstract <strong><code>RouteBuilder</code></strong> class and put the
error handling logic in its <strong
><code>configure</code></strong> method. And then extend this class, and make
>sure to class <strong><code>super.configure()</code></strong>. We are just
>using the Java inheritance technique.</p></div></div><p> </p><h3
>id="ExceptionClause-HowDoesCamelSelectWhichClauseShouldHandleaGivenThrownException?">How
> Does Camel Select Which Clause Should Handle a Given Thrown
>Exception?</h3><p>Camel uses
><strong><code>DefaultExceptionPolicyStrategy</code></strong> to determine a
>strategy how an exception being thrown should be handled by which
><strong><code>onException</code></strong> clause. The strategy is:</p><ul
>class="alternate"><li>the order in which the
><strong><code>onException</code></strong> is configured takes precedence.
>Camel will test from first...last defined.</li><li>Camel will start from the
>bottom (nested caused by) and recursive up in the exception hierarchy to find
>the first matching <strong><code>onException</code></strong>
>clause.</li><li><strong><code>instanceof</cod
e></strong> test is used for testing the given exception with the
<strong><code>onException</code></strong> clause defined exception list. An
exact <strong><code>instanceof</code></strong> match will always be used,
otherwise the <strong><code>onException</code></strong> clause that has an
exception that is the closets super of the thrown exception is selected
(recurring up the exception hierarchy).</li></ul><p>This is best illustrated
with an exception:</p><div class="code panel pdl" style="border-width:
1px;"><div class="codeContent panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[onException(IOException.class)
+from("seda:order")
+ .to("bean:processOrder");
+</plain-text-body><h3 id="ExceptionClause-Scopes">Scopes</h3><p>Exception
clauses is scoped as either:</p><ul class="alternate"><li>global (for Java DSL
that is per <strong><code>RouteBuilder</code></strong> instances, to
reuse, see note below)</li><li>or route specific</li></ul><p>Where the
<strong>global</strong> are the simplest and most easy to understand. In the
advanced section we dig into the route specific and even combining them.
However</p><p> </p><rich-text-body><p>Global scope for Java DSL is per
<strong><code>RouteBuilder</code></strong> instance, so if you want to share
among multiple <strong><code>RouteBuilder</code></strong> classes, then create
a base abstract <strong><code>RouteBuilder</code></strong> class and put the
error handling logic in its <strong><code>configure</code></strong> method. And
then extend this class, and make sure to class
<strong><code>super.configure()</code></strong>. We are just using the Java
inheritance technique.</p></rich-text
-body><p> </p><h3
id="ExceptionClause-HowDoesCamelSelectWhichClauseShouldHandleaGivenThrownException?">How
Does Camel Select Which Clause Should Handle a Given Thrown
Exception?</h3><p>Camel uses
<strong><code>DefaultExceptionPolicyStrategy</code></strong> to determine a
strategy how an exception being thrown should be handled by which
<strong><code>onException</code></strong> clause. The strategy is:</p><ul
class="alternate"><li>the order in which the
<strong><code>onException</code></strong> is configured takes precedence. Camel
will test from first...last defined.</li><li>Camel will start from the bottom
(nested caused by) and recursive up in the exception hierarchy to find the
first matching <strong><code>onException</code></strong>
clause.</li><li><strong><code>instanceof</code></strong> test is used for
testing the given exception with the <strong><code>onException</code></strong>
clause defined exception list. An exact
<strong><code>instanceof</code></strong> match will
always be used, otherwise the <strong><code>onException</code></strong> clause
that has an exception that is the closets super of the thrown exception is
selected (recurring up the exception hierarchy).</li></ul><p>This is best
illustrated with an exception:</p><parameter
ac:name="language">java</parameter><plain-text-body>onException(IOException.class)
.maximumRedeliveries(3);
onException(OrderFailedException.class)
.maximumRedeliveries(2);
-]]></script>
-</div></div><p>In the sample above we have defined two exceptions in
which <strong><code>IOException</code></strong> is first, so Camel will
pickup this exception if there is a
match. <strong><code>IOException</code></strong> that is more general is
selected then.</p><p>So if an exception is thrown with this hierarchy:</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[+ RuntimeCamelException (wrapper exception by
Camel)
+</plain-text-body><p>In the sample above we have defined two exceptions in
which <strong><code>IOException</code></strong> is first, so Camel will
pickup this exception if there is a
match. <strong><code>IOException</code></strong> that is more general is
selected then.</p><p>So if an exception is thrown with this
hierarchy:</p><plain-text-body>+ RuntimeCamelException (wrapper exception by
Camel)
+ OrderFailedException
+ IOException
+ FileNotFoundException
-]]></script>
-</div></div><p>Then Camel will try testing the exception in this order:
<strong><code>FileNotFoundException</code>,
<code>IOException</code></strong>, <strong><code>OrderFailedException</code></strong>
and <strong><code>RuntimeCamelException</code>.</strong><br clear="none"> As
we have defined
a <strong><code>onException(IOException.class)</code></strong> Camel will
select this as it's the <strong>closest</strong> match.</p><p>If we add a
third <strong><code>onException</code></strong> clause with the
<strong><code>FileNotFoundException</code></strong></p><div class="code panel
pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[onException(IOException.class)
+</plain-text-body><p>Then Camel will try testing the exception in this order:
<strong><code>FileNotFoundException</code>,
<code>IOException</code></strong>, <strong><code>OrderFailedException</code></strong>
and <strong><code>RuntimeCamelException</code>.</strong><br clear="none"> As
we have defined
a <strong><code>onException(IOException.class)</code></strong> Camel will
select this as it's the <strong>closest</strong> match.</p><p>If we add a
third <strong><code>onException</code></strong> clause with the
<strong><code>FileNotFoundException</code></strong></p><parameter
ac:name="">java</parameter><plain-text-body>onException(IOException.class)
.maximumRedeliveries(3);
onException(OrderFailedException.class)
@@ -129,600 +109,78 @@ onException(OrderFailedException.class)
onException(FileNotFoundException.class)
.handled(true)
- .to("log:nofile");
-]]></script>
-</div></div><p>Then with the previous example Camel will now use the last
<strong><code>onException(FileNotFoundException.class)</code></strong> as its
an <strong>exact</strong> match. Since this is an exact match it will override
the general <strong><code>IOException</code></strong> that was used before
to handle the same exception thrown.</p><p>Now a new situation if this
exception was thrown instead:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[+ RuntimeCamelException (wrapper exception by
Camel)
+ .to("log:nofile");
+</plain-text-body><p>Then with the previous example Camel will now use the
last <strong><code>onException(FileNotFoundException.class)</code></strong> as
its an <strong>exact</strong> match. Since this is an exact match it will
override the general <strong><code>IOException</code></strong> that was
used before to handle the same exception thrown.</p><p>Now a new situation if
this exception was thrown instead:</p><plain-text-body>+ RuntimeCamelException
(wrapper exception by Camel)
+ OrderFailedException
+ OrderNotFoundException
-]]></script>
-</div></div><p>Then the
<strong><code>onException(OrderFailedException.class)</code></strong> will be
selected - no surprise here.</p><p>And this last sample demonstrates the
<strong><code>instanceof</code></strong> test aspect in which Camel will select
an exception if it's an instance of the defined exception in the
<strong><code>onException</code></strong> clause. Illustrated as:</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[+ RuntimeCamelException (wrapper exception by
Camel)
+</plain-text-body><p>Then the
<strong><code>onException(OrderFailedException.class)</code></strong> will be
selected - no surprise here.</p><p>And this last sample demonstrates the
<strong><code>instanceof</code></strong> test aspect in which Camel will select
an exception if it's an instance of the defined exception in the
<strong><code>onException</code></strong> clause. Illustrated
as:</p><plain-text-body>+ RuntimeCamelException (wrapper exception by Camel)
+ SocketException
-]]></script>
-</div></div><p>Since <strong><code>SocketException</code></strong> is an
<strong><code>instanceof IOException</code></strong>, Camel will select the
<strong><code>onException(IOException.class)</code></strong> clause.</p><h3
id="ExceptionClause-ConfiguringRedeliveryPolicy(redeliveroptions)">Configuring
RedeliveryPolicy (redeliver options)</h3><p><a shape="rect"
class="external-link"
href="http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/processor/RedeliveryPolicy.html";>RedeliveryPolicy</a>
requires to use the <a shape="rect" href="dead-letter-channel.html">Dead
Letter Channel</a> as the <a shape="rect" href="error-handler.html">Error
Handler</a>. Dead Letter Channel supports attempting to redeliver the message
exchange a number of times before sending it to a dead letter endpoint. See <a
shape="rect" href="dead-letter-channel.html">Dead Letter Channel</a> for
further information about redeliver and which redeliver options exists.</p><div
class="confluen
ce-information-macro confluence-information-macro-information"><p
class="title">No redelivery is default for onException</p><span class="aui-icon
aui-icon-small aui-iconfont-info confluence-information-macro-icon"></span><div
class="confluence-information-macro-body"><p>By default any <a shape="rect"
href="exception-clause.html">Exception Clause</a> will <strong>not</strong>
redeliver! (as it sets the <code>maximumRedeliveries</code> option to
0).</p></div></div><p>Sometimes you want to configure the redelivery policy on
a per exception type basis. By default in the top examples, if an
<strong><code>org.apache.camel.ValidationException</code></strong> occurs then
the message will not be redelivered; however if some other exception occurs,
e.g., <strong><code>IOException</code></strong> or whatever, the route will be
retried according to the settings from the <a shape="rect"
href="dead-letter-channel.html">Dead Letter Channel</a>.</p><p>However if you
want to customize any methods on
the <a shape="rect" class="external-link"
href="http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/processor/RedeliveryPolicy.html";>RedeliveryPolicy</a>
object, you can do this via the fluent API. So lets retry in case
of <strong><code>org.apache.camel.ValidationException</code></strong> up
till two times.</p><p><strong>Java DSL</strong>:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[onException(ValidationException.class)
+</plain-text-body><p>Since <strong><code>SocketException</code></strong>
is an <strong><code>instanceof IOException</code></strong>, Camel will select
the <strong><code>onException(IOException.class)</code></strong> clause.</p><h3
id="ExceptionClause-ConfiguringRedeliveryPolicy(redeliveroptions)">Configuring
RedeliveryPolicy (redeliver options)</h3><p><a shape="rect"
class="external-link"
href="http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/processor/RedeliveryPolicy.html";>RedeliveryPolicy</a>
requires to use the <a shape="rect" href="dead-letter-channel.html">Dead
Letter Channel</a> as the <a shape="rect" href="error-handler.html">Error
Handler</a>. Dead Letter Channel supports attempting to redeliver the message
exchange a number of times before sending it to a dead letter endpoint. See <a
shape="rect" href="dead-letter-channel.html">Dead Letter Channel</a> for
further information about redeliver and which redeliver options
exists.</p><parameter ac:
name="title">No redelivery is default for
onException</parameter><rich-text-body><p>By default any <a shape="rect"
href="exception-clause.html">Exception Clause</a> will <strong>not</strong>
redeliver! (as it sets the <code>maximumRedeliveries</code> option to
0).</p></rich-text-body><p>Sometimes you want to configure the redelivery
policy on a per exception type basis. By default in the top examples, if an
<strong><code>org.apache.camel.ValidationException</code></strong> occurs then
the message will not be redelivered; however if some other exception occurs,
e.g., <strong><code>IOException</code></strong> or whatever, the route will be
retried according to the settings from the <a shape="rect"
href="dead-letter-channel.html">Dead Letter Channel</a>.</p><p>However if you
want to customize any methods on the <a shape="rect" class="external-link"
href="http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/processor/RedeliveryPolicy.html";>RedeliveryPolicy</a>
objec
t, you can do this via the fluent API. So lets retry in case
of <strong><code>org.apache.camel.ValidationException</code></strong> up
till two times.</p><p><strong>Java DSL</strong>:</p><parameter
ac:name="language">java</parameter><plain-text-body>onException(ValidationException.class)
.maximumRedeliveries(2);
-]]></script>
-</div></div><p><strong> Spring XML DSL</strong>:</p><div class="code panel
pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<script class="brush: xml; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[<onException>
+</plain-text-body><p><strong> Spring XML DSL</strong>:</p><parameter
ac:name="">xml</parameter><plain-text-body><onException>
<exception>com.mycompany.ValidationException</exception>
- <redeliveryPolicy maximumRedeliveries="2"/>
+ <redeliveryPolicy maximumRedeliveries="2"/>
</onException>
-]]></script>
-</div></div><p>You can customize any of the <a shape="rect"
class="external-link"
href="http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/processor/RedeliveryPolicy.html";>RedeliveryPolicy</a>
so we can for instance set a different delay
of <strong><code>5000</code></strong> millis:</p><div class="code panel
pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<script class="brush: xml; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[<onException>
+</plain-text-body><p>You can customize any of the <a shape="rect"
class="external-link"
href="http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/processor/RedeliveryPolicy.html";>RedeliveryPolicy</a>
so we can for instance set a different delay
of <strong><code>5000</code></strong> millis:</p><parameter
ac:name="language">xml</parameter><plain-text-body><onException>
<exception>com.mycompany.ValidationException</exception>
- <redeliveryPolicy maximumRedeliveries="2"
delay="5000"/>
+ <redeliveryPolicy maximumRedeliveries="2" delay="5000"/>
</onException>
-]]></script>
-</div></div><h4 id="ExceptionClause-PointofEntryforRedeliveryAttempts">Point
of Entry for Redelivery Attempts</h4><p>All redelivery attempts start at the
point of the failure. So the route:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[.onException(ConnectException.class)
-.from("direct:start")
- .process("processor1")
- .process("processor2") // <--- throws a ConnectException
-.to("mock:theEnd")
-]]></script>
-</div></div><p>Will retry from <strong><code>processor2</code></strong> -
not the complete route.</p><h4
id="ExceptionClause-ReusingRedeliveryPolicy">Reusing
RedeliveryPolicy</h4><p><strong>Available as of Camel 1.5.1 or
later</strong><br clear="none"> You can reference a
<strong><code>RedeliveryPolicy</code></strong> so you can reuse existing
configurations and use standard spring bean style configuration that supports
property placeholders.</p><div class="code panel pdl" style="border-width:
1px;"><div class="codeContent panelContent pdl">
-<script class="brush: xml; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[<bean id="myRedeliveryPolicy"
class="org.apache.camel.processor.RedeliveryPolicy">
- <property name="maximumRedeliveries"
value="${myprop.max}"/>
+</plain-text-body><h4
id="ExceptionClause-PointofEntryforRedeliveryAttempts">Point of Entry for
Redelivery Attempts</h4><p>All redelivery attempts start at the point of the
failure. So the route:</p><parameter
ac:name="language">java</parameter><plain-text-body>.onException(ConnectException.class)
+.from("direct:start")
+ .process("processor1")
+ .process("processor2") // <--- throws a ConnectException
+.to("mock:theEnd")
+</plain-text-body><p>Will retry
from <strong><code>processor2</code></strong> - not the complete
route.</p><h4 id="ExceptionClause-ReusingRedeliveryPolicy">Reusing
RedeliveryPolicy</h4><p><strong>Available as of Camel 1.5.1 or
later</strong><br clear="none"> You can reference a
<strong><code>RedeliveryPolicy</code></strong> so you can reuse existing
configurations and use standard spring bean style configuration that supports
property placeholders.</p><parameter
ac:name="">xml</parameter><plain-text-body><bean id="myRedeliveryPolicy"
class="org.apache.camel.processor.RedeliveryPolicy">
+ <property name="maximumRedeliveries" value="${myprop.max}"/>
</bean>
<!-- here we reference our redelivery policy defined above -->
-<onException redeliveryPolicyRef="myRedeliveryPolicy">
+<onException redeliveryPolicyRef="myRedeliveryPolicy">
<!-- you can define multiple exceptions just adding more exception
elements as show below -->
<exception>com.mycompany.MyFirstException</exception>
<exception>com.mycompany.MySecondException</exception>
</onException>
-]]></script>
-</div></div><h3
id="ExceptionClause-AsynchronousDelayedRedelivery">Asynchronous Delayed
Redelivery</h3><p><strong>Available as of Camel 2.4</strong></p><p>From
<strong>Camel 2.4</strong>: Camel has a feature to <strong>not block</strong>
while waiting for a delayed redelivery to occur. However if you use transacted
routes then Camel will block as its mandated by the transaction manager to
execute all the work in the same thread context. You can enable the non
blocking asynchronous behavior by the
<strong><code>asyncDelayedRedelivery</code></strong> option. This option can be
set on the <strong><code>errorHandler</code></strong>,
<strong><code>onException</code></strong> or the redelivery policies.</p><p>By
default the error handler will create and use a scheduled thread pool to
trigger redelivery in the future. From <strong>Camel 2.8</strong>: you can
configure the <strong><code>executorServiceRef</code></strong> on the <a
shape="rect" href="error-handler.html">Error Handler</a> to
indicate a reference to either a shared thread pool you can enlist in the
registry, or a thread pool profile in case you want to be able to control pool
settings.</p><h3 id="ExceptionClause-CatchingMultipleExceptions">Catching
Multiple Exceptions</h3><p><strong>Available as of Camel 1.5</strong></p><p>In
Camel 1.5 the <strong>exception</strong> clauses has been renamed to
<strong><code>onException</code></strong> and it also supports multiple
exception classes:</p><div class="code panel pdl" style="border-width:
1px;"><div class="codeContent panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[onException(MyBusinessException.class,
MyOtherBusinessException.class)
+</plain-text-body><h3
id="ExceptionClause-AsynchronousDelayedRedelivery">Asynchronous Delayed
Redelivery</h3><p><strong>Available as of Camel 2.4</strong></p><p>From
<strong>Camel 2.4</strong>: Camel has a feature to <strong>not block</strong>
while waiting for a delayed redelivery to occur. However if you use transacted
routes then Camel will block as its mandated by the transaction manager to
execute all the work in the same thread context. You can enable the non
blocking asynchronous behavior by the
<strong><code>asyncDelayedRedelivery</code></strong> option. This option can be
set on the <strong><code>errorHandler</code></strong>,
<strong><code>onException</code></strong> or the redelivery policies.</p><p>By
default the error handler will create and use a scheduled thread pool to
trigger redelivery in the future. From <strong>Camel 2.8</strong>: you can
configure the <strong><code>executorServiceRef</code></strong> on the <a
shape="rect" href="error-handler.html">Error Handler</
a> to indicate a reference to either a shared thread pool you can enlist in
the registry, or a thread pool profile in case you want to be able to control
pool settings.</p><h3 id="ExceptionClause-CatchingMultipleExceptions">Catching
Multiple Exceptions</h3><p><strong>Available as of Camel 1.5</strong></p><p>In
Camel 1.5 the <strong>exception</strong> clauses has been renamed to
<strong><code>onException</code></strong> and it also supports multiple
exception classes:</p><parameter
ac:name="language">java</parameter><plain-text-body>onException(MyBusinessException.class,
MyOtherBusinessException.class)
.maximumRedeliveries(2)
- .to("activemq:businessFailed");
-]]></script>
-</div></div><p>And in Spring DSL you just add another exception
element:</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
-<script class="brush: xml; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[<onException>
+ .to("activemq:businessFailed");
+</plain-text-body><p>And in Spring DSL you just add another exception
element:</p><parameter
ac:name="language">xml</parameter><plain-text-body><onException>
<exception>com.mycompany.MyBusinessException</exception>
<exception>com.mycompany.MyOtherBusinessException</exception>
- <redeliveryPolicy maximumRedeliveries="2"/>
- <to uri="activemq:businessFailed"/>
+ <redeliveryPolicy maximumRedeliveries="2"/>
+ <to uri="activemq:businessFailed"/>
</onException>
-]]></script>
-</div></div><h3 id="ExceptionClause-UsingaProcessorasaFailureHandler">Using a
Processor as a Failure Handler</h3><p>We want to handle certain exceptions
specially so we add a <strong><code>onException</code></strong> clause for
that exception.</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[
-// here we register exception cause for MyFunctionException
-// when this exception occur we want it to be processed by our processor
-onException(MyFunctionalException.class).process(new
MyFunctionFailureHandler()).stop();
-]]></script>
-</div></div>So what happens is that whenever a
<strong><code>MyFunctionalException</code></strong> is thrown it is being
routed to our processor <strong><code>MyFunctionFailureHandler</code></strong>.
So you can say that the exchange is diverted when
a <strong><code>MyFunctionalException</code></strong> is thrown during
processing. It's important to distinct this as perfect valid. The default
redelivery policy from the <a shape="rect" href="dead-letter-channel.html">Dead
Letter Channel</a> will not kick in, so our processor receives the Exchange
directly, without any redeliver attempted. In our processor we need to
determine what to do. Camel regards the Exchange as <strong>failure
handled</strong>. So our processor is the end of the route. So lets look the
code for our processor.<div class="code panel pdl" style="border-width:
1px;"><div class="codeContent panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[
-public static class MyFunctionFailureHandler implements Processor {
-
- public void process(Exchange exchange) throws Exception {
- // the caused by exception is stored in a property on the exchange
- Throwable caused = exchange.getProperty(Exchange.EXCEPTION_CAUGHT,
Throwable.class);
- assertNotNull(caused);
- // here you can do what you want, but Camel regard this exception as
handled, and
- // this processor as a failurehandler, so it wont do redeliveries. So
this is the
- // end of this route. But if we want to route it somewhere we can just
get a
- // producer template and send it.
-
- // send it to our mock endpoint
-
exchange.getContext().createProducerTemplate().send("mock:myerror",
exchange);
- }
-}
-]]></script>
-</div></div>Notice how we get the <strong>caused by</strong> exception using a
property on the Exchange. This is where Camel stores any caught exception
during processing. So you can fetch this property and check what the exception
message and do what you want. In the code above we just route it to a mock
endpoint using a producer template from Exchange.<h2
id="ExceptionClause-MarkingExceptionsasHandled">Marking Exceptions as
Handled</h2><p><strong>Available as of Camel 1.5</strong></p><div
class="confluence-information-macro confluence-information-macro-tip"><p
class="title">Continued</p><span class="aui-icon aui-icon-small
aui-iconfont-approve confluence-information-macro-icon"></span><div
class="confluence-information-macro-body"><p>See also the section <em>Handle
and continue exceptions</em>
below</p></div></div><p>Using <strong><code>onException</code></strong> 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 behavior with the
new <strong>handle</strong> DSL. The handle is a <a shape="rect"
href="predicate.html">Predicate</a> that is overloaded to accept three types of
parameters:</p><ul class="alternate"><li>Boolean</li><li><a shape="rect"
href="predicate.html">Predicate</a></li><li><a shape="rect"
href="expression.html">Expression</a> that will be evaluates as a <a
shape="rect" href="predicate.html">Predicate</a> using this rule set: If the
expressions returns a Boolean its used directly. For any other response its
regarded as <code>true</code> if the response is <code>not
null</code>.</li></ul><p>For instance to mark all
<strong><code>ValidationException</code></strong> as being handled we can do
this:</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[onException(ValidationException)
+</plain-text-body><h3
id="ExceptionClause-UsingaProcessorasaFailureHandler">Using a Processor as a
Failure Handler</h3><p>We want to handle certain exceptions specially so we add
a <strong><code>onException</code></strong> clause for that
exception.<plain-text-body>{snippet:id=e1|lang=java|url=camel/trunk/camel-core/src/test/java/org/apache/camel/processor/onexception/OnExceptionProcessorInspectCausedExceptionTest.java}</plain-text-body>So
what happens is that whenever a
<strong><code>MyFunctionalException</code></strong> is thrown it is being
routed to our processor <strong><code>MyFunctionFailureHandler</code></strong>.
So you can say that the exchange is diverted when
a <strong><code>MyFunctionalException</code></strong> is thrown during
processing. It's important to distinct this as perfect valid. The default
redelivery policy from the <a shape="rect" href="dead-letter-channel.html">Dead
Letter Channel</a> will not kick in, so our processor receives the Exchange
direct
ly, without any redeliver attempted. In our processor we need to determine
what to do. Camel regards the Exchange as <strong>failure handled</strong>. So
our processor is the end of the route. So lets look the code for our
processor.<plain-text-body>{snippet:id=e2|lang=java|url=camel/trunk/camel-core/src/test/java/org/apache/camel/processor/onexception/OnExceptionProcessorInspectCausedExceptionTest.java}</plain-text-body>Notice
how we get the <strong>caused by</strong> exception using a property on the
Exchange. This is where Camel stores any caught exception during processing. So
you can fetch this property and check what the exception message and do what
you want. In the code above we just route it to a mock endpoint using a
producer template from Exchange.</p><h2
id="ExceptionClause-MarkingExceptionsasHandled">Marking Exceptions as
Handled</h2><p><strong>Available as of Camel 1.5</strong></p><parameter
ac:name="title">Continued</parameter><rich-text-body><p>See also the section <
em>Handle and continue exceptions</em>
below</p></rich-text-body><p>Using <strong><code>onException</code></strong>
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 behavior with the new <strong>handle</strong> DSL. The handle
is a <a shape="rect" href="predicate.html">Predicate</a> that is overloaded to
accept three types of parameters:</p><ul
class="alternate"><li>Boolean</li><li><a shape="rect"
href="predicate.html">Predicate</a></li><li><a shape="rect"
href="expression.html">Expression</a> that will be evaluates as a <a
shape="rect" href="predicate.html">Predicate</a> using this rule set: If the
expressions returns a Boolean its used directly. For any other response its
regarded as <code>true</code> if the response is <code>not
null</code>.</li></ul><p>For instance to mark all
<strong><code>ValidationException</code></strong> as being handled we can do
this:</p><parameter
ac:name="language">java</parameter><plain-text-body>onException(ValidationException)
.handled(true);
-]]></script>
-</div></div><h3 id="ExceptionClause-ExampleUsingHandled">Example Using
Handled</h3><p>In this route below we want to do special handling of
all <strong><code>OrderFailedException</code></strong> as we want to
return a customized response to the caller. First we setup our routing
as:</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[
-// we do special error handling for when OrderFailedException is thrown
-onException(OrderFailedException.class)
- // we mark the exchange as handled so the caller doesn't receive the
- // OrderFailedException but whatever we want to return instead
- .handled(true)
- // this bean handles the error handling where we can customize the error
- // response using java code
- .bean(OrderService.class, "orderFailed")
- // and since this is an unit test we use mocks for testing
- .to("mock:error");
-
-// this is just the generic error handler where we set the destination
-// and the number of redeliveries we want to try
-errorHandler(deadLetterChannel("mock:error").maximumRedeliveries(1));
-
-// this is our route where we handle orders
-from("direct:start")
- // this bean is our order service
- .bean(OrderService.class, "handleOrder")
- // this is the destination if the order is OK
- .to("mock:result");
-]]></script>
-</div></div>Then we have our service beans that is just plain POJO
demonstrating how you can use <a shape="rect" href="bean-integration.html">Bean
Integration</a> in Camel to avoid being tied to the Camel API:<div class="code
panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[
-/**
- * Order service as a plain POJO class
- */
-public static class OrderService {
-
- /**
- * This method handle our order input and return the order
- *
- * @param in the in headers
- * @param payload the in payload
- * @param out the out headers
- * @return the out payload
- * @throws OrderFailedException is thrown if the order cannot be processed
- */
- public Object handleOrder(@Headers Map<?, ?> in, @Body String
payload, @OutHeaders Map<String, Object> out)
- throws OrderFailedException {
- out.put("customerid", in.get("customerid"));
- if ("Order: kaboom".equals(payload)) {
- throw new OrderFailedException("Cannot order: kaboom");
- } else {
- out.put("orderid", "123");
- return "Order OK";
- }
- }
-
- /**
- * This method creates the response to the caller if the order could not
be processed
- * @param in the in headers
- * @param payload the in payload
- * @param out the out headers
- * @return the out payload
- */
- public Object orderFailed(@Headers Map<?, ?> in, @Body String
payload, @OutHeaders Map<String, Object> out) {
- out.put("customerid", in.get("customerid"));
- out.put("orderid", "failed");
- return "Order ERROR";
- }
-}
-]]></script>
-</div></div>And finally the exception that is being thrown is just a regular
exception:<div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[
-/**
- * Exception thrown if the order cannot be processed
- */
-public static class OrderFailedException extends Exception {
-
- private static final long serialVersionUID = 1L;
-
- public OrderFailedException(String message) {
- super(message);
- }
-
-}
-]]></script>
-</div></div>So what happens?<p>If we sent an order that is being processed OK
then the caller will receive an Exchange as reply containing
<strong><code>Order OK</code></strong> as the payload and
<strong><code>orderid=123</code></strong> in a header.</p><p>If the order could
<strong>not</strong> be processed and thus
an <strong><code>OrderFailedException</code></strong> was thrown the
caller will <strong>not</strong> receive this exception (as opposed to in Camel
1.4, where the caller received the
<strong><code>OrderFailedException</code></strong>) but our customized response
that we have fabricated in the <strong><code>orderFailed</code></strong> method
in our <strong><code>OrderService</code></strong>. So the caller receives an
Exchange with the payload <strong><code>Order ERROR</code></strong> and a
<strong><code>orderid=failed</code></strong> in a header.</p><h3
id="ExceptionClause-UsingHandledwithSpringDSL">Using Handled with Spring
DSL</h3><p>The same route as above in S
pring DSL:</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
-<script class="brush: xml; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[
-<!-- setup our error handler as the deal letter channel -->
-<bean id="errorHandler"
class="org.apache.camel.builder.DeadLetterChannelBuilder">
- <property name="deadLetterUri"
value="mock:error"/>
-</bean>
-
-<!-- this is our POJO bean with our business logic defined as a plain
spring bean -->
-<bean id="orderService"
class="org.apache.camel.spring.processor.onexception.OrderService"
/>
-
-<!-- this is the camel context where we define the routes -->
-<!-- define our error handler as a global error handler -->
-<camelContext errorHandlerRef="errorHandler"
xmlns="http://camel.apache.org/schema/spring">
-
- <onException>
- <!-- the exception is full qualified names as plain strings -->
- <!-- there can be more just add a 2nd, 3rd exception element
(unbounded) -->
-
<exception>org.apache.camel.spring.processor.onexception.OrderFailedException</exception>
- <!-- we can set the redelivery policy here as well -->
- <redeliveryPolicy maximumRedeliveries="1" />
- <!-- mark this as handled -->
- <handled>
- <constant>true</constant>
- </handled>
- <!-- let our order service handle this exception, call the orderFailed
method -->
- <bean ref="orderService" method="orderFailed" />
- <!-- and since this is a unit test we use mock for assertions -->
- <to uri="mock:error" />
- </onException>
-
- <route>
- <!-- the route -->
- <from uri="direct:start" />
- <!-- in the normal route then route to our order service and call
handleOrder method -->
- <bean ref="orderService" method="handleOrder" />
- <!-- and since this is a unit test we use mock for assertions -->
- <to uri="mock:result" />
- </route>
-
-</camelContext>
-]]></script>
-</div></div><h3
id="ExceptionClause-HandlingandSendingaFixedResponseBacktotheClient">Handling
and Sending a Fixed Response Back to the Client</h3><p>In the route above we
handled the exception but routed it to a different endpoint. What if you need
to alter the response and send a fixed response back to the original caller
(the client). No secret here just do as you do in normal Camel routing, use <a
shape="rect" href="message-translator.html">transform</a> to set the response,
as shown in the sample below:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[
-// we catch MyFunctionalException and want to mark it as handled (= no failure
returned to client)
-// but we want to return a fixed text response, so we transform OUT body as
Sorry.
-onException(MyFunctionalException.class)
- .handled(true)
- .transform().constant("Sorry");
-]]></script>
-</div></div>We modify the sample slightly to return the original caused
exception message instead of the fixed text Sorry:<div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[
-// we catch MyFunctionalException and want to mark it as handled (= no failure
returned to client)
-// but we want to return a fixed text response, so we transform OUT body and
return the exception message
-onException(MyFunctionalException.class)
- .handled(true)
- .transform(exceptionMessage());
-]]></script>
-</div></div>And we can use the <a shape="rect" href="simple.html">Simple</a>
language to set a readable error message with the caused exception message:<div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[
-// we catch MyFunctionalException and want to mark it as handled (= no failure
returned to client)
-// but we want to return a fixed text response, so we transform OUT body and
return a nice message
-// using the simple language where we want insert the exception message
-onException(MyFunctionalException.class)
- .handled(true)
- .transform().simple("Error reported: ${exception.message} -
cannot process this message.");
-]]></script>
-</div></div><h2 id="ExceptionClause-HandleandContinueExceptions">Handle and
Continue Exceptions</h2><p><strong>Available as of Camel 2.3</strong></p><p>In
Camel 2.3 we introduced a new option <code>continued</code> which allows you to
both <strong><code>handle</code></strong>
and <strong><code>continue</code></strong> routing in the original route
as if the exception did not occur.</p><p>For example: to ignore and continue
when the <strong><code>IDontCareException</code></strong> was thrown we can do
this:</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[
onException(IDontCareException).continued(true);
-]]></script>
-</div></div><p>You can maybe compare continued with a having a
<strong><code>try ... catch</code></strong> block around each step and then
just ignore the exception. Using continued makes it easier in Camel as you
otherwise had to use <a shape="rect" href="try-catch-finally.html">Try Catch
Finally</a> style for this kind of use case.</p><h3
id="ExceptionClause-ExampleUsingcontinued">Example Using continued</h3><p>In
this route below we want to do special handling of
all <strong><code>IllegalArgumentException</code></strong> as we just want
to continue routing.</p><div class="code panel pdl" style="border-width:
1px;"><div class="codeContent panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[
-public void configure() throws Exception {
- // tell Camel to handle and continue when this exception is thrown
- onException(IllegalArgumentException.class).continued(true);
-
- from("direct:start")
- .to("mock:start")
- .throwException(new IllegalArgumentException("Forced"))
- .to("mock:result");
-}
-]]></script>
-</div></div>And the same example in Spring XML:<div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<script class="brush: xml; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[
-<camelContext xmlns="http://camel.apache.org/schema/spring">
-
- <onException>
- <exception>java.lang.IllegalArgumentException</exception>
- <!-- tell Camel to handle and continue when this exception was
thrown -->
-
<continued><constant>true</constant></continued>
- </onException>
-
- <route>
- <from uri="direct:start"/>
- <to uri="mock:start"/>
- <throwException ref="forced"/>
- <to uri="mock:result"/>
- </route>
-
-</camelContext>
-]]></script>
-</div></div><h3
id="ExceptionClause-WhatistheDifferenceBetweenHandledandContinued?">What is the
Difference Between Handled and Continued?</h3><p>If handled is true, then the
thrown exception will be <em>handled</em> and Camel will <strong>not</strong>
continue routing in the original route, but break out. However you can
configure a route in the <strong><code>onException</code></strong> which will
be used instead. You use this route if you need to create some custom response
message back to the caller, or do any other processing because that exception
was thrown.</p><p>If continued is true, then Camel will catch the exception and
in fact just ignore it and continue routing in the original route. However if
you have a route configured in the <strong><code>onException</code></strong> it
will route that route first, before it will continue routing in the original
route.</p><h3
id="ExceptionClause-UsinguseOriginalMessage">Using <code>useOriginalMessage</code></h3><p><strong>Availab
le as of Camel 2.0</strong><br clear="none"> The
option <strong><code>useOriginalMessage</code></strong> is used for
routing the original input body instead of the current body that potential is
modified during routing.</p><p>For example: if you have this route:</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[from("jms:queue:order:input")
- .to("bean:validateOrder");
- .to("bean:transformOrder")
- .to("bean:handleOrder");
-]]></script>
-</div></div><p>The route listen for JMS messages and validates, transforms and
handle it. During this the <a shape="rect" href="exchange.html">Exchange</a>
payload is transformed/modified. So in case something goes wrong and we want to
move the message to another JMS destination, then we can add an
<strong><code>onException</code></strong>. But when we move the <a shape="rect"
href="exchange.html">Exchange</a> to this destination we do not know in which
state the message is in. Did the error happen in before
the <strong><code>transformOrder</code></strong> or after? So to be sure
we want to move the original input message we received from
<code>jms:queue:order:input</code>. So we can do this by enabling the
<strong><code>useOriginalMessage</code></strong> option as shown below:</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[// will use original input body
+</plain-text-body><h3 id="ExceptionClause-ExampleUsingHandled">Example Using
Handled</h3><p>In this route below we want to do special handling of
all <strong><code>OrderFailedException</code></strong> as we want to
return a customized response to the caller. First we setup our routing
as:<plain-text-body>{snippet:id=e1|lang=java|url=camel/trunk/camel-core/src/test/java/org/apache/camel/processor/DeadLetterChannelHandledExampleTest.java}</plain-text-body>Then
we have our service beans that is just plain POJO demonstrating how you can
use <a shape="rect" href="bean-integration.html">Bean Integration</a> in Camel
to avoid being tied to the Camel
API:<plain-text-body>{snippet:id=e2|lang=java|url=camel/trunk/camel-core/src/test/java/org/apache/camel/processor/DeadLetterChannelHandledExampleTest.java}</plain-text-body>And
finally the exception that is being thrown is just a regular
exception:<plain-text-body>{snippet:id=e3|lang=java|url=camel/trunk/camel-core/src/test/java/org/apache
/camel/processor/DeadLetterChannelHandledExampleTest.java}</plain-text-body>So
what happens?</p><p>If we sent an order that is being processed OK then the
caller will receive an Exchange as reply containing <strong><code>Order
OK</code></strong> as the payload and <strong><code>orderid=123</code></strong>
in a header.</p><p>If the order could <strong>not</strong> be processed and
thus an <strong><code>OrderFailedException</code></strong> was thrown the
caller will <strong>not</strong> receive this exception (as opposed to in Camel
1.4, where the caller received the
<strong><code>OrderFailedException</code></strong>) but our customized response
that we have fabricated in the <strong><code>orderFailed</code></strong> method
in our <strong><code>OrderService</code></strong>. So the caller receives an
Exchange with the payload <strong><code>Order ERROR</code></strong> and a
<strong><code>orderid=failed</code></strong> in a header.</p><h3
id="ExceptionClause-UsingHandledwithSpringDS
L">Using Handled with Spring DSL</h3><p>The same route as above in Spring
DSL:<plain-text-body>{snippet:id=e1|lang=xml|url=camel/trunk/components/camel-spring/src/test/resources/org/apache/camel/spring/processor/onexception/deadLetterChannelHandledExampleTest.xml}</plain-text-body></p><h3
id="ExceptionClause-HandlingandSendingaFixedResponseBacktotheClient">Handling
and Sending a Fixed Response Back to the Client</h3><p>In the route above we
handled the exception but routed it to a different endpoint. What if you need
to alter the response and send a fixed response back to the original caller
(the client). No secret here just do as you do in normal Camel routing, use <a
shape="rect" href="message-translator.html">transform</a> to set the response,
as shown in the sample
below:<plain-text-body>{snippet:id=e1|lang=java|url=camel/trunk/camel-core/src/test/java/org/apache/camel/processor/onexception/OnExceptionHandleAndTransformTest.java}</plain-text-body>We
modify the sample slightly to
return the original caused exception message instead of the fixed text
Sorry:<plain-text-body>{snippet:id=e2|lang=java|url=camel/trunk/camel-core/src/test/java/org/apache/camel/processor/onexception/OnExceptionHandleAndTransformTest.java}</plain-text-body>And
we can use the <a shape="rect" href="simple.html">Simple</a> language to set a
readable error message with the caused exception
message:<plain-text-body>{snippet:id=e3|lang=java|url=camel/trunk/camel-core/src/test/java/org/apache/camel/processor/onexception/OnExceptionHandleAndTransformTest.java}</plain-text-body></p><h2
id="ExceptionClause-HandleandContinueExceptions">Handle and Continue
Exceptions</h2><p><strong>Available as of Camel 2.3</strong></p><p>In Camel 2.3
we introduced a new option <code>continued</code> which allows you to
both <strong><code>handle</code></strong>
and <strong><code>continue</code></strong> routing in the original route
as if the exception did not occur.</p><p>For example: to ignore and c
ontinue when the <strong><code>IDontCareException</code></strong> was thrown
we can do this:</p><plain-text-body>
onException(IDontCareException).continued(true);
+</plain-text-body><p>You can maybe compare continued with a having a
<strong><code>try ... catch</code></strong> block around each step and then
just ignore the exception. Using continued makes it easier in Camel as you
otherwise had to use <a shape="rect" href="try-catch-finally.html">Try Catch
Finally</a> style for this kind of use case.</p><h3
id="ExceptionClause-ExampleUsingcontinued">Example Using continued</h3><p>In
this route below we want to do special handling of
all <strong><code>IllegalArgumentException</code></strong> as we just want
to continue
routing.<plain-text-body>{snippet:id=e1|lang=java|url=camel/trunk/camel-core/src/test/java/org/apache/camel/processor/onexception/OnExceptionContinueTest.java}</plain-text-body>And
the same example in Spring
XML:<plain-text-body>{snippet:id=e1|lang=xml|url=camel/trunk/components/camel-spring/src/test/resources/org/apache/camel/spring/processor/onexception/OnExceptionContinueTest.xml}</plain-text-body></p><h3
id="ExceptionCla
use-WhatistheDifferenceBetweenHandledandContinued?">What is the Difference
Between Handled and Continued?</h3><p>If handled is true, then the thrown
exception will be <em>handled</em> and Camel will <strong>not</strong> continue
routing in the original route, but break out. However you can configure a route
in the <strong><code>onException</code></strong> which will be used instead.
You use this route if you need to create some custom response message back to
the caller, or do any other processing because that exception was
thrown.</p><p>If continued is true, then Camel will catch the exception and in
fact just ignore it and continue routing in the original route. However if you
have a route configured in the <strong><code>onException</code></strong> it
will route that route first, before it will continue routing in the original
route.</p><h3
id="ExceptionClause-UsinguseOriginalMessage">Using <code>useOriginalMessage</code></h3><p><strong>Available
as of Camel 2.0</strong><br c
lear="none"> The option <strong><code>useOriginalMessage</code></strong>
is used for routing the original input body instead of the current body that
potential is modified during routing.</p><p>For example: if you have this
route:</p><parameter
ac:name="language">java</parameter><plain-text-body>from("jms:queue:order:input")
+ .to("bean:validateOrder");
+ .to("bean:transformOrder")
+ .to("bean:handleOrder");
+</plain-text-body><p>The route listen for JMS messages and validates,
transforms and handle it. During this the <a shape="rect"
href="exchange.html">Exchange</a> payload is transformed/modified. So in case
something goes wrong and we want to move the message to another JMS
destination, then we can add an <strong><code>onException</code></strong>. But
when we move the <a shape="rect" href="exchange.html">Exchange</a> to this
destination we do not know in which state the message is in. Did the error
happen in before the <strong><code>transformOrder</code></strong> or
after? So to be sure we want to move the original input message we received
from <code>jms:queue:order:input</code>. So we can do this by enabling the
<strong><code>useOriginalMessage</code></strong> option as shown
below:</p><parameter ac:name="">java</parameter><plain-text-body>// will use
original input body
onException(MyOrderException.class)
.useOriginalMessage()
.handled(true)
- .to("jms:queue:order:failed");
-]]></script>
-</div></div><p>Then the messages routed to the
<strong><code>jms:queue:order:failed</code></strong> is the original input. If
we want to manually retry we can move the JMS message from the failed to the
input queue, with no problem as the message is the same as the original we
received.</p><h4
id="ExceptionClause-useOriginalMessagewithSpringDSL"><code>useOriginalMessage</code>
with Spring
DSL</h4><p>The <strong><code>useOriginalMessage</code></strong> option is
defined as a boolean attribute on
the <strong><code><onException></code></strong> XML tag in Spring
DSL. So the definition above would be:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<script class="brush: xml; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[<onException
useOriginalMessage="true">
+ .to("jms:queue:order:failed");
+</plain-text-body><p>Then the messages routed to the
<strong><code>jms:queue:order:failed</code></strong> is the original input. If
we want to manually retry we can move the JMS message from the failed to the
input queue, with no problem as the message is the same as the original we
received.</p><h4
id="ExceptionClause-useOriginalMessagewithSpringDSL"><code>useOriginalMessage</code>
with Spring
DSL</h4><p>The <strong><code>useOriginalMessage</code></strong> option is
defined as a boolean attribute on
the <strong><code><onException></code></strong> XML tag in Spring
DSL. So the definition above would be:</p><parameter
ac:name="">xml</parameter><plain-text-body><onException
useOriginalMessage="true">
<exception>com.mycompany.MyOrderException</exception>
<handled><constant>true</constant></handled>
- <to uri="jms:queue:order:failed"/>
-</onException>
-]]></script>
-</div></div><h2 id="ExceptionClause-AdvancedUsageof">Advanced Usage of <a
shape="rect" href="exception-clause.html">Exception Clause</a></h2><h3
id="ExceptionClause-UsingGlobalandPerRouteExceptionClauses">Using Global and
Per Route Exception Clauses</h3><p>Camel supports quite advanced configuration
of exception clauses.</p><p>You can define exception clauses either as:</p><ul
class="alternate"><li>global</li><li>or route specific</li></ul><p>We start off
with the sample sample that we change over time. First off we use only global
exception clauses:</p><div class="code panel pdl" style="border-width:
1px;"><div class="codeContent panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[
-
-// default should errors go to mock:error
-errorHandler(deadLetterChannel("mock:error").redeliveryDelay(0));
-
-// if a MyTechnicalException is thrown we will not try to redeliver and we
mark it as handled
-// so the caller does not get a failure
-// since we have no to then the exchange will continue to be routed to the
normal error handler
-// destination that is mock:error as defined above
-onException(MyTechnicalException.class).maximumRedeliveries(0).handled(true);
-
-// if a MyFunctionalException is thrown we do not want Camel to redelivery but
handle it our self using
-// our bean myOwnHandler, then the exchange is not routed to the default error
(mock:error)
-onException(MyFunctionalException.class).maximumRedeliveries(0).handled(true).to("bean:myOwnHandler");
-
-// here we route message to our service bean
-from("direct:start")
- .choice()
- .when().xpath("//type =
'myType'").to("bean:myServiceBean")
- .end()
- .to("mock:result");
-]]></script>
-</div></div>In the next sample we change the global exception policies to be
pure route specific.<div class="confluence-information-macro
confluence-information-macro-information"><p class="title">Must use .end() for
route specific exception policies</p><span class="aui-icon aui-icon-small
aui-iconfont-info confluence-information-macro-icon"></span><div
class="confluence-information-macro-body"><p><strong>Important:</strong> This
requires to end the <strong><code>onException</code></strong> route with
<strong><code>.end()</code></strong> to indicate where it stops and when the
regular route continues.</p></div></div><p></p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[
-// default should errors go to mock:error
-errorHandler(deadLetterChannel("mock:error"));
-
-// here we start the routing with the consumer
-from("direct:start")
-
- // if a MyTechnicalException is thrown we will not try to redeliver and we
mark it as handled
- // so the caller does not get a failure
- // since we have no to then the exchange will continue to be routed to the
normal error handler
- // destination that is mock:error as defined above
- // we MUST use .end() to indicate that this sub block is ended
-
.onException(MyTechnicalException.class).maximumRedeliveries(0).handled(true).end()
-
- // if a MyFunctionalException is thrown we do not want Camel to redelivery
but handle it our self using
- // our bean myOwnHandler, then the exchange is not routed to the default
error (mock:error)
- // we MUST use .end() to indicate that this sub block is ended
-
.onException(MyFunctionalException.class).maximumRedeliveries(0).handled(true).to("bean:myOwnHandler").end()
-
- // here we have the regular routing
- .choice()
- .when().xpath("//type =
'myType'").to("bean:myServiceBean")
- .end()
- .to("mock:result");
-]]></script>
-</div></div>And now it gets complex as we combine global and route specific
exception policies as we introduce a second route in the sample:<div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[
-// global error handler
-// as its based on a unit test we do not have any delays between and do not
log the stack trace
-errorHandler(deadLetterChannel("mock:error").redeliveryDelay(0).logStackTrace(false));
-
-// shared for both routes
-onException(MyTechnicalException.class).handled(true).maximumRedeliveries(2).to("mock:tech.error");
-
-from("direct:start")
- // route specific on exception for MyFunctionalException
- // we MUST use .end() to indicate that this sub block is ended
- .onException(MyFunctionalException.class).maximumRedeliveries(0).end()
- .to("bean:myServiceBean")
- .to("mock:result");
-
-from("direct:start2")
- // route specific on exception for MyFunctionalException that is different
than the previous route
- // here we marked it as handled and send it to a different destination
mock:handled
- // we MUST use .end() to indicate that this sub block is ended
-
.onException(MyFunctionalException.class).handled(true).maximumRedeliveries(0).to("mock:handled").end()
- .to("bean:myServiceBean")
- .to("mock:result");
-]]></script>
-</div></div>Notice that we can define the same
exception <strong><code>MyFunctionalException</code></strong> in both
routes, but they are configured differently and thus is handled different
depending on the route. You can of course also add a
new <strong><code>onException</code></strong> to one of the routes so it
has an additional exception policy.<p>And finally we top this by throwing in a
nested error handler as well, as we add the 3rd route shown below:</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[
-from("direct:start3")
- // route specific error handler that is different than the global error
handler
- // here we do not redeliver and send errors to mock:error3 instead of the
global endpoint
- .errorHandler(deadLetterChannel("mock:error3")
- .maximumRedeliveries(0))
-
- // route specific on exception to mark MyFunctionalException as being
handled
- .onException(MyFunctionalException.class).handled(true).end()
- // however we want the IO exceptions to redeliver at most 3 times
- .onException(IOException.class).maximumRedeliveries(3).end()
- .to("bean:myServiceBean")
- .to("mock:result");
-]]></script>
-</div></div><div class="confluence-information-macro
confluence-information-macro-information"><p class="title">Global exception
policies and nested error handlers</p><span class="aui-icon aui-icon-small
aui-iconfont-info confluence-information-macro-icon"></span><div
class="confluence-information-macro-body"><p>The sample above with both nested
error handlers and both global and per route exception clauses is a bit
advanced. It's important to get the fact straight that the
<strong>global</strong> exception clauses is really global so they also applies
for nested error handlers. So if a
<strong><code>MyTechnicalException</code></strong> is thrown then it's the
global exception policy that is selected.</p></div></div><h3
id="ExceptionClause-UsingFineGrainedSelectionUsingonWhenPredicate">Using Fine
Grained Selection Using <code>onWhen</code>
Predicate</h3><p><strong>Available as of Camel 1.5.1 or
later</strong></p><p>You can attach an <a shape="rect"
href="expression.html">Expres
sion</a> to the exception clause to have fine grained control when a clause
should be selected or not. As it's an <a shape="rect"
href="expression.html">Expression</a> you can use any kind of code to perform
the test. Here is a sample:</p><div class="code panel pdl" style="border-width:
1px;"><div class="codeContent panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[
-public void configure() throws Exception {
-
errorHandler(deadLetterChannel("mock:error").redeliveryDelay(0).maximumRedeliveries(3));
-
- // here we define our onException to catch MyUserException when
- // there is a header[user] on the exchange that is not null
-
onException(MyUserException.class).onWhen(header("user").isNotNull())
- .maximumRedeliveries(1)
- // setting delay to zero is just to make unit testing faster
- .redeliveryDelay(0)
- .to(ERROR_USER_QUEUE);
-
- // here we define onException to catch MyUserException as a kind
- // of fallback when the above did not match.
- // Notice: The order how we have defined these onException is
- // important as Camel will resolve in the same order as they
- // have been defined
- onException(MyUserException.class)
- .maximumRedeliveries(2)
- // setting delay to zero is just to make unit testing faster
- .redeliveryDelay(0)
- .to(ERROR_QUEUE);
-]]></script>
-</div></div>In the sample above we have two
<strong><code>onException</code></strong>'s defined. The first has
an <strong><code>onWhen</code></strong> expression attached to only
trigger if the message has a header with the key user that is not null. If so
this clause is selected and is handling the thrown exception. The second clause
is a for coarse gained selection to select the same exception being thrown but
when the expression is evaluated to false.<p><strong>Note:</strong> this is not
required, if the second clause is omitted, then the default error handler will
kick in.</p><h3
id="ExceptionClause-UsingonRedeliveryProcessor">Using <code>onRedelivery</code>
Processor</h3><p><strong>Available as of Camel 2.0</strong></p><p><a
shape="rect" href="dead-letter-channel.html">Dead Letter Channel</a> has
support for <strong><code>onRedelivery</code></strong> to allow custom
processing of a Message before its being redelivered. It can be used to add
some customer header o
r whatnot. In Camel 2.0 we have added this feature to <a shape="rect"
href="exception-clause.html">Exception Clause</a> as well, so you can use per
exception scoped on redelivery. Camel will fallback to use the one defined on
<a shape="rect" href="dead-letter-channel.html">Dead Letter Channel</a> if any,
if none exists on the <a shape="rect" href="exception-clause.html">Exception
Clause</a>. See <a shape="rect" href="dead-letter-channel.html">Dead Letter
Channel</a> for more details on
<strong><code>onRedelivery</code></strong>.</p><p>In the code below we want to
do some custom code before redelivering any
<strong><code>IOException</code></strong>. So we configure
an <strong><code>onException</code></strong> for
the <strong><code>IOException</code></strong> and set
the <strong><code>onRedelivery</code></strong> to use our custom
processor:</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[
-// when we redeliver caused by an IOException we want to do some special
-// code before the redeliver attempt
-onException(IOException.class)
- // try to redeliver at most 3 times
- .maximumRedeliveries(3)
- // setting delay to zero is just to make unit testing faster
- .redeliveryDelay(0)
- .onRedelivery(new MyIORedeliverProcessor());
-]]></script>
-</div></div>And in our custom processor we set a special timeout header to the
message. You can of course do anything what you like in your code.<div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[
-// This is our processor that is executed before IOException redeliver attempt
-// here we can do what we want in the java code, such as altering the message
-
-public static class MyIORedeliverProcessor implements Processor {
-
- public void process(Exchange exchange) throws Exception {
- // just for show and tell, here we set a special header to instruct
- // the receive a given timeout value
- exchange.getIn().setHeader("Timeout", 5000);
- }
-}
-]]></script>
-</div></div><h4
id="ExceptionClause-UsingonRedeliveryinSpringDSL">Using <code>onRedelivery</code>
in Spring DSL</h4><p>In Spring DSL you need to use the
<strong><code>onRedeliveryRef</code></strong> attribute to refer to a spring
bean id that is your custom processor:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<script class="brush: xml; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[
-<onException onRedeliveryRef="myIORedeliverProcessor">
- <exception>java.io.IOException</exception>
+ <to uri="jms:queue:order:failed"/>
</onException>
-]]></script>
-</div></div>And our processor is just a regular spring bean (we
use <strong><code>$</code></strong> for the inner class as this code is
based on unit testing):<div class="code panel pdl" style="border-width:
1px;"><div class="codeContent panelContent pdl">
-<script class="brush: xml; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[
-<bean id="myRedeliveryProcessor"
-
class="org.apache.camel.processor.DeadLetterChannelOnExceptionOnRedeliveryTest$MyRedeliverProcessor"/>
-]]></script>
-</div></div><h3
id="ExceptionClause-UsingonExceptionOccurredProcessor">Using <code>onExceptionOccurred</code>
Processor</h3><p><strong>Available as of Camel 2.17</strong></p><p><a
shape="rect" href="dead-letter-channel.html">Dead Letter Channel</a> has
support for <strong><code>onExceptionOccurred</code></strong> to allow
custom processing of a Message just after the exception was thrown. It can be
used to do some custom logging or whatnot. The difference
between <strong><code>onRedelivery</code></strong> processor
and <strong><code>onExceptionOccurred</code></strong> processor, is that
the former is processed just before a redelivery attempt is being performed,
that means it will not happen right after an exception was thrown. For example
if the error handler has been configured to perform 5 seconds delay between
redelivery attempts, then the redelivery processor is invoked 5 seconds later
sine the exception was thrown. On the other hand the <strong><c
ode>onExceptionOccurred</code></strong> processor is always invoked right
after the exception was thrown, and also if redelivery has been
disabled.</p><p><strong>Note: </strong>Any new exceptions thrown from
the <strong><code>onExceptionOccurred</code></strong> processor is logged
as <strong><code>WARN</code></strong> and ignored, to not override the
existing exception. </p><p>In the code below we want to do some custom
logging when an exception happened. Therefore we configure
an <strong><code>onExceptionOccurred</code></strong> to use our custom
processor:</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[errorHandler(defaultErrorHandler()
+</plain-text-body><h2 id="ExceptionClause-AdvancedUsageof">Advanced Usage of
<a shape="rect" href="exception-clause.html">Exception Clause</a></h2><h3
id="ExceptionClause-UsingGlobalandPerRouteExceptionClauses">Using Global and
Per Route Exception Clauses</h3><p>Camel supports quite advanced configuration
of exception clauses.</p><p>You can define exception clauses either as:</p><ul
class="alternate"><li>global</li><li>or route specific</li></ul><p>We start off
with the sample sample that we change over time. First off we use only global
exception
clauses:<plain-text-body>{snippet:id=e1|lang=java|url=camel/trunk/camel-core/src/test/java/org/apache/camel/processor/onexception/OnExceptionRouteTest.java}</plain-text-body>In
the next sample we change the global exception policies to be pure route
specific.</p><parameter ac:name="title">Must use .end() for route specific
exception policies</parameter><rich-text-body><p><strong>Important:</strong>
This requires to end the <strong><co
de>onException</code></strong> route with <strong><code>.end()</code></strong>
to indicate where it stops and when the regular route
continues.</p></rich-text-body><p><plain-text-body>{snippet:id=e1|lang=java|url=camel/trunk/camel-core/src/test/java/org/apache/camel/processor/onexception/OnExceptionSubRouteTest.java}</plain-text-body>And
now it gets complex as we combine global and route specific exception policies
as we introduce a second route in the
sample:<plain-text-body>{snippet:id=e1|lang=java|url=camel/trunk/camel-core/src/test/java/org/apache/camel/processor/onexception/OnExceptionComplexRouteTest.java}</plain-text-body>Notice
that we can define the same
exception <strong><code>MyFunctionalException</code></strong> in both
routes, but they are configured differently and thus is handled different
depending on the route. You can of course also add a
new <strong><code>onException</code></strong> to one of the routes so it
has an additional exception policy.</p><p>And
finally we top this by throwing in a nested error handler as well, as we add
the 3rd route shown
below:<plain-text-body>{snippet:id=e1|lang=java|url=camel/trunk/camel-core/src/test/java/org/apache/camel/processor/onexception/OnExceptionComplexWithNestedErrorHandlerRouteTest.java}</plain-text-body></p><parameter
ac:name="title">Global exception policies and nested error
handlers</parameter><rich-text-body><p>The sample above with both nested error
handlers and both global and per route exception clauses is a bit advanced.
It's important to get the fact straight that the <strong>global</strong>
exception clauses is really global so they also applies for nested error
handlers. So if a <strong><code>MyTechnicalException</code></strong> is thrown
then it's the global exception policy that is selected.</p></rich-text-body><h3
id="ExceptionClause-UsingFineGrainedSelectionUsingonWhenPredicate">Using Fine
Grained Selection Using <code>onWhen</code>
Predicate</h3><p><strong>Available as
of Camel 1.5.1 or later</strong></p><p>You can attach an <a shape="rect"
href="expression.html">Expression</a> to the exception clause to have fine
grained control when a clause should be selected or not. As it's an <a
shape="rect" href="expression.html">Expression</a> you can use any kind of code
to perform the test. Here is a
sample:<plain-text-body>{snippet:id=e1|lang=java|url=camel/trunk/camel-core/src/test/java/org/apache/camel/processor/exceptionpolicy/DefaultExceptionPolicyStrategyUsingWhenTest.java}</plain-text-body>In
the sample above we have two <strong><code>onException</code></strong>'s
defined. The first has an <strong><code>onWhen</code></strong> expression
attached to only trigger if the message has a header with the key user that is
not null. If so this clause is selected and is handling the thrown exception.
The second clause is a for coarse gained selection to select the same exception
being thrown but when the expression is evaluated to false.</p><p><strong>
Note:</strong> this is not required, if the second clause is omitted, then the
default error handler will kick in.</p><h3
id="ExceptionClause-UsingonRedeliveryProcessor">Using <code>onRedelivery</code>
Processor</h3><p><strong>Available as of Camel 2.0</strong></p><p><a
shape="rect" href="dead-letter-channel.html">Dead Letter Channel</a> has
support for <strong><code>onRedelivery</code></strong> to allow custom
processing of a Message before its being redelivered. It can be used to add
some customer header or whatnot. In Camel 2.0 we have added this feature to <a
shape="rect" href="exception-clause.html">Exception Clause</a> as well, so you
can use per exception scoped on redelivery. Camel will fallback to use the one
defined on <a shape="rect" href="dead-letter-channel.html">Dead Letter
Channel</a> if any, if none exists on the <a shape="rect"
href="exception-clause.html">Exception Clause</a>. See <a shape="rect"
href="dead-letter-channel.html">Dead Letter Channel</a> for
more details on <strong><code>onRedelivery</code></strong>.</p><p>In the code
below we want to do some custom code before redelivering any
<strong><code>IOException</code></strong>. So we configure
an <strong><code>onException</code></strong> for
the <strong><code>IOException</code></strong> and set
the <strong><code>onRedelivery</code></strong> to use our custom
processor:<plain-text-body>{snippet:id=e1|lang=java|url=camel/trunk/camel-core/src/test/java/org/apache/camel/processor/DeadLetterChannelOnExceptionOnRedeliveryTest.java}</plain-text-body>And
in our custom processor we set a special timeout header to the message. You
can of course do anything what you like in your
code.<plain-text-body>{snippet:id=e4|lang=java|url=camel/trunk/camel-core/src/test/java/org/apache/camel/processor/DeadLetterChannelOnExceptionOnRedeliveryTest.java}</plain-text-body></p><h4
id="ExceptionClause-UsingonRedeliveryinSpringDSL">Using <code>onRedelivery</code>
in Spring DSL</h4><p>
In Spring DSL you need to use the
<strong><code>onRedeliveryRef</code></strong> attribute to refer to a spring
bean id that is your custom
processor:<plain-text-body>{snippet:id=e1|lang=xml|url=camel/trunk/components/camel-spring/src/test/resources/org/apache/camel/spring/processor/onexception/DeadLetterChannelOnExceptionOnRedeliveryTest.xml}</plain-text-body>And
our processor is just a regular spring bean (we
use <strong><code>$</code></strong> for the inner class as this code is
based on unit
testing):<plain-text-body>{snippet:id=e2|lang=xml|url=camel/trunk/components/camel-spring/src/test/resources/org/apache/camel/spring/processor/onexception/DeadLetterChannelOnExceptionOnRedeliveryTest.xml}</plain-text-body></p><h3
id="ExceptionClause-UsingonExceptionOccurredProcessor">Using <code>onExceptionOccurred</code>
Processor</h3><p><strong>Available as of Camel 2.17</strong></p><p><a
shape="rect" href="dead-letter-channel.html">Dead Letter Channel</a> has
support for
0;<strong><code>onExceptionOccurred</code></strong> to allow custom processing
of a Message just after the exception was thrown. It can be used to do some
custom logging or whatnot. The difference
between <strong><code>onRedelivery</code></strong> processor
and <strong><code>onExceptionOccurred</code></strong> processor, is that
the former is processed just before a redelivery attempt is being performed,
that means it will not happen right after an exception was thrown. For example
if the error handler has been configured to perform 5 seconds delay between
redelivery attempts, then the redelivery processor is invoked 5 seconds later
sine the exception was thrown. On the other hand
the <strong><code>onExceptionOccurred</code></strong> processor is always
invoked right after the exception was thrown, and also if redelivery has been
disabled.</p><p><strong>Note: </strong>Any new exceptions thrown from
the <strong><code>onExceptionOccurred</code></strong> proces
sor is logged as <strong><code>WARN</code></strong> and ignored, to not
override the existing exception. </p><p>In the code below we want to do
some custom logging when an exception happened. Therefore we configure
an <strong><code>onExceptionOccurred</code></strong> to use our custom
processor:</p><plain-text-body>errorHandler(defaultErrorHandler()
.maximumRedeliveries(3)
.redeliveryDelay(5000)
- .onExceptionOccurred(myProcessor));]]></script>
-</div></div><h4
id="ExceptionClause-UsingonRedeliveryinSpringDSL.1">Using <code>onRedelivery</code>
in Spring DSL</h4><p>In Spring DSL you need to use
the <strong><code>onExceptionOccurredRef</code></strong> attribute to
refer to a spring bean id that is your custom processor:</p><div class="code
panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<script class="brush: xml; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[<bean id="myProcessor"
class="com.foo.MyExceptionLoggingProcessor"/>
-Â
-<camelContext errorHandlerRef="eh"
xmlns="http://camel.apache.org/schema/spring">
+ .onExceptionOccurred(myProcessor));</plain-text-body><h4
id="ExceptionClause-UsingonRedeliveryinSpringDSL.1">Using <code>onRedelivery</code>
in Spring DSL</h4><p>In Spring DSL you need to use
the <strong><code>onExceptionOccurredRef</code></strong> attribute to
refer to a spring bean id that is your custom processor:</p><parameter
ac:name="">xml</parameter><plain-text-body><bean id="myProcessor"
class="com.foo.MyExceptionLoggingProcessor"/>
+ 
+<camelContext errorHandlerRef="eh"
xmlns="http://camel.apache.org/schema/spring">
- <errorHandler id="eh" type="DefaultErrorHandler"
onExceptionOccurredRef="myProcessor">
- <redeliveryPolicy maximumRedeliveries="3"
redeliveryDelay="5000"/>
+ <errorHandler id="eh" type="DefaultErrorHandler"
onExceptionOccurredRef="myProcessor">
+ <redeliveryPolicy maximumRedeliveries="3" redeliveryDelay="5000"/>
</errorHandler>
...
-</camelContext>]]></script>
-</div></div><h3
id="ExceptionClause-UsingFineGrainedRetryUsingretryWhilePredicate">Using Fine
Grained Retry Using <code>retryWhile</code>
Predicate</h3><p><strong>Available as of Camel 2.0</strong></p><div
class="confluence-information-macro
confluence-information-macro-information"><span class="aui-icon aui-icon-small
aui-iconfont-info confluence-information-macro-icon"></span><div
class="confluence-information-macro-body"><p>In Camel 2.0 to 2.3 its called
<strong><code>retryUntil</code></strong>. From <strong>Camel 2.4</strong>: its
named <strong><code>retryWhile</code></strong> because Camel will continue
doing retries <em>while</em> the predicate returns true.</p></div></div><p>When
you need fine grained control for determining if an exchange should be retried
or not you can use the <strong><code>retryWhile</code></strong> predicate.
Camel will redeliver until the predicate returns false.</p><p>Example:</p><div
class="code panel pdl" style="border-width: 1px;"><di
v class="codeContent panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[
-// we want to use a predicate for retries so we can determine in our bean
-// when retry should stop, notice it will overrule the global error handler
-// where we defined at most 1 redelivery attempt. Here we will continue until
-// the predicate returns false
-onException(MyFunctionalException.class)
- .retryWhile(method("myRetryHandler"))
- .handled(true)
- .transform().constant("Sorry");
-]]></script>
-</div></div>Where the bean <strong><code>myRetryHandler</code></strong>
is computing if we should retry or not:<div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<script class="brush: java; gutter: false; theme: Default"
type="syntaxhighlighter"><![CDATA[
-public class MyRetryBean {
-
- // using bean binding we can bind the information from the exchange to the
types we have in our method signature
[... 130 lines stripped ...]
