Modified: websites/production/camel/content/exception-clause.html
==============================================================================
--- websites/production/camel/content/exception-clause.html (original)
+++ websites/production/camel/content/exception-clause.html Tue Oct 18 17:19:28 
2016
@@ -86,88 +86,96 @@
        <tbody>
         <tr>
         <td valign="top" width="100%">
-<div class="wiki-content maincontent"><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>onException()</strong> method.</p><p>To get started we give quick 
sample before digging into how it works.<br clear="none"> 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(&quot;activemq:validationFailed&quot;);
+<div class="wiki-content maincontent"><p>&#160;</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(&quot;activemq:validationFailed&quot;);
   
-from(&quot;seda:inputA&quot;).
-  to(&quot;validation:foo/bar.xsd&quot;, &quot;activemq:someQueue&quot;);
+from(&quot;seda:inputA&quot;)
+  .to(&quot;validation:foo/bar.xsd&quot;, &quot;activemq:someQueue&quot;);
 
-from(&quot;seda:inputB&quot;).to(&quot;direct:foo&quot;).
-  to(&quot;rnc:mySchema.rnc&quot;, &quot;activemq:anotherQueue&quot;);
-]]></script>
-</div></div><p>Here if the processing of <strong>seda:inputA</strong> or 
<strong>seda:inputB</strong> cause a ValidationException 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 <strong>activemq:validationFailed</strong> 
queue.</p><p>You can define multiple onException 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(&quot;activemq:validationFailed&quot;);
-
-onException(ShipOrderException.class).
-  to(&quot;activemq:shipFailed&quot;);
-
-from(&quot;seda:order&quot;).to(&quot;bean:processOrder&quot;);
-]]></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 
RouteBuilder 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>&#160;</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 
<code>RouteBuilder</code> instance, so if you want to share among multiple 
<code>RouteBuilder</code> classes, then create a base abstract 
<code>RouteBuilder</code> class and put the error handling logic in its 
<code>configure</code> method. And then extend this class, and make sure to 
class <code>super
 .configure()</code>. We are just using the Java inheritance 
technique.</p></div></div><p>&#160;</p><h3 
id="ExceptionClause-HowdoesCamelselectwhichclauseshouldhandleagiventhrownException">How
 does Camel select which clause should handle a given thrown 
Exception</h3><p>Camel uses <code>DefaultExceptionPolicyStrategy</code> to 
determine a strategy how an exception being thrown should be handled by which 
<code>onException</code> clause. The strategy is:</p><ul 
class="alternate"><li>the order in which the <code>onException</code> 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 
<code>onException</code> clause</li><li><code>instanceof</code> test is used 
for testing the given exception with the <code>onException</code> clause 
defined exception list. An exact <code>instanceof</code> match will always be 
used, otherwise the <code>onExce
 ption</code> 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).maximumRedeliveries(3);
+from(&quot;seda:inputB&quot;)
+  .to(&quot;direct:foo&quot;)
+  .to(&quot;rnc:mySchema.rnc&quot;, &quot;activemq:anotherQueue&quot;);
+]]></script>
+</div></div><p>Here if the processing of 
<strong><code>seda:inputA</code></strong> 
or&#160;<strong><code>seda:inputB</code></strong> cause 
a&#160;<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&#160;<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(&quot;activemq:validationFailed&quot;);
+
+onException(ShipOrderException.class)
+  .to(&quot;activemq:shipFailed&quot;);
+
+from(&quot;seda:order&quot;)
+  .to(&quot;bean:processOrder&quot;);
+]]></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&#160;<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>&#160;</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>&#160;</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)
+  .maximumRedeliveries(3);
 
-onException(OrderFailedException.class).maximumRedeliveries(2);
+onException(OrderFailedException.class)
+  .maximumRedeliveries(2);
 ]]></script>
-</div></div><p>In the sample above we have defined two exceptions in which 
IOException is first, so Camel will pickup this exception if there is a match. 
IOException 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">
+</div></div><p>In the sample above we have defined two exceptions in 
which&#160;<strong><code>IOException</code></strong> is first, so Camel will 
pickup this exception if there is a 
match.&#160;<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)
    + OrderFailedException 
        + IOException
             + FileNotFoundException
 ]]></script>
-</div></div><p>Then Camel will try testing the exception in this order: 
FileNotFoundException, IOException, OrderFailedException and 
RuntimeCamelException.<br clear="none"> As we have defined a 
onException(IOException.class) Camel will select this as it's the 
<strong>closest</strong> match.</p><p>If we add a third onException clause with 
the <code>FileNotFoundException</code></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).maximumRedeliveries(3);
+</div></div><p>Then Camel will try testing the exception in this order: 
<strong><code>FileNotFoundException</code>, 
<code>IOException</code></strong>,&#160;<strong><code>OrderFailedException</code></strong>
 and <strong><code>RuntimeCamelException</code>.</strong><br clear="none"> As 
we have defined 
a&#160;<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&#160;<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)
+  .maximumRedeliveries(3);
 
-onException(OrderFailedException.class).maximumRedeliveries(2);
+onException(OrderFailedException.class)
+  .maximumRedeliveries(2);
 
-onException(FileNotFoundException.class).handled(true).to(&quot;log:nofile&quot;);
+onException(FileNotFoundException.class)
+  .handled(true)
+  .to(&quot;log:nofile&quot;);
 ]]></script>
-</div></div><p>Then with the previous example Camel will now use the last 
<code>onException(FileNotFoundException.class)</code> as its an 
<strong>exact</strong> match. Since this is an exact match it will override the 
general IOException 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">
+</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&#160;<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)
    + OrderFailedException 
        + OrderNotFoundException
 ]]></script>
-</div></div><p>Then the <code>onException(OrderFailedException.class)</code> 
will be selected - no surprise here.</p><p>And this last sample demonstrates 
the <code>instanceof</code> test aspect in which Camel will select an exception 
if it's an instance of the defined exception in the <code>onException</code> 
clause. Illustrated as:</p><div class="code panel pdl" style="border-width: 
1px;"><div class="codeContent panelContent pdl">
+</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)
    + SocketException
 ]]></script>
-</div></div><p>Since SocketException is an instanceof IOException, Camel will 
select the <code>onException(IOException.class)</code> 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="confluence-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 a 
ValidationException occurs then the message will not be redelivered; however if 
some other exception occurs (IOException or whatelse) 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";>Redelivery
 Policy</a> object, you can do this via the fluent API. So lets retry in case 
of ValidationException up till two times.</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).
-  maximumRedeliveries(2);
+</div></div><p>Since&#160;<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&#160;<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)
+  .maximumRedeliveries(2);
 ]]></script>
-</div></div><p>And the spring DSL:</p><div class="code panel pdl" 
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+</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[&lt;onException&gt;
    &lt;exception&gt;com.mycompany.ValidationException&lt;/exception&gt;
    &lt;redeliveryPolicy maximumRedeliveries=&quot;2&quot;/&gt;
 &lt;/onException&gt;
 ]]></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 5000 millis:</p><div 
class="code panel pdl" style="border-width: 1px;"><div class="codeContent 
panelContent pdl">
+</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&#160;<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[&lt;onException&gt;
    &lt;exception&gt;com.mycompany.ValidationException&lt;/exception&gt;
    &lt;redeliveryPolicy maximumRedeliveries=&quot;2&quot; 
delay=&quot;5000&quot;/&gt;
 &lt;/onException&gt;
 ]]></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">
+</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(&quot;direct:start&quot;)
  .process(&quot;processor1&quot;)
  .process(&quot;processor2&quot;) // &lt;--- throws a ConnectException
 .to(&quot;mock:theEnd&quot;)
 ]]></script>
-</div></div><p>Will retry from <strong>processor2</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 
<code>RedeliveryPolicy</code> 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[    &lt;bean 
id=&quot;myRedeliveryPolicy&quot; 
class=&quot;org.apache.camel.processor.RedeliveryPolicy&quot;&gt;
-        &lt;property name=&quot;maximumRedeliveries&quot; 
value=&quot;${myprop.max}&quot;/&gt;
-    &lt;/bean&gt;
-
-     &lt;!-- here we reference our redelivery policy defined above --&gt;
-     &lt;onException redeliveryPolicyRef=&quot;myRedeliveryPolicy&quot;&gt;
-         &lt;!-- you can define multiple exceptions just adding more exception 
elements as show below --&gt;
-         &lt;exception&gt;com.mycompany.MyFirstException&lt;/exception&gt;
-         &lt;exception&gt;com.mycompany.MySecondException&lt;/exception&gt;
-     &lt;/onException&gt;
+</div></div><p>Will retry from&#160;<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[&lt;bean id=&quot;myRedeliveryPolicy&quot; 
class=&quot;org.apache.camel.processor.RedeliveryPolicy&quot;&gt;
+  &lt;property name=&quot;maximumRedeliveries&quot; 
value=&quot;${myprop.max}&quot;/&gt;
+&lt;/bean&gt;
+
+&lt;!-- here we reference our redelivery policy defined above --&gt;
+&lt;onException redeliveryPolicyRef=&quot;myRedeliveryPolicy&quot;&gt;
+  &lt;!-- you can define multiple exceptions just adding more exception 
elements as show below --&gt;
+  &lt;exception&gt;com.mycompany.MyFirstException&lt;/exception&gt;
+  &lt;exception&gt;com.mycompany.MySecondException&lt;/exception&gt;
+&lt;/onException&gt;
 ]]></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> onwards 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 <code>asyncDelayedRedelivery</code> 
option. This option can be set on the <code>errorHandler</code>, 
<code>onException</code> 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> onwards you can configure the 
<code>executorServiceRef</code> on the <a shape="rect" 
href="error-handler.html">Error Handler</a> to indicate a reference to either a 
shared thread pool yo
 u 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>onException</strong> and it also supports multiple exception 
classes:</p><div class="code panel pdl" style="border-width: 1px;"><div 
class="codeContent panelContent pdl">
+</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)
   .maximumRedeliveries(2)
   .to(&quot;activemq:businessFailed&quot;);
@@ -180,13 +188,13 @@ onException(FileNotFoundException.class)
    &lt;to uri=&quot;activemq:businessFailed&quot;/&gt;
 &lt;/onException&gt;
 ]]></script>
-</div></div><h3 id="ExceptionClause-Usingaprocessorasfailurehandler">Using a 
processor as failure handler</h3><p>We want to handle certain exceptions 
specially so we add a <strong>onException</strong> clause for that 
exception.</p><div class="code panel pdl" style="border-width: 1px;"><div 
class="codeContent panelContent pdl">
+</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&#160;<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 
<code>MyFunctionalException</code> is thrown it is being routed to our 
processor <code>MyFunctionFailureHandler</code>. So you can say that the 
exchange is diverted when a MyFunctionalException 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">
+</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&#160;<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 {
 
@@ -204,10 +212,11 @@ public static class MyFunctionFailureHan
     }
 }
 ]]></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-Markingexceptionsasbeinghandled">Marking exceptions as 
being 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>onException</strong> to handle known exceptions is a very powerful 
feature in Camel. However prior to Camel 1.5 you could not mark the except
 ion 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 
<code>ValidationException</code> 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).handled(true);
+</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&#160;<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)
+  .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 
OrderFailedException 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">
+</div></div><h3 id="ExceptionClause-ExampleUsingHandled">Example Using 
Handled</h3><p>In this route below we want to do special handling of 
all&#160;<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)
@@ -287,7 +296,7 @@ public static class OrderFailedException
     
 }
 ]]></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 <code>Order 
OK</code> as the payload and <code>orderid=123</code> in a header.</p><p>If the 
order could <strong>not</strong> be processed and thus an OrderFailedException 
was thrown the caller will <strong>not</strong> 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 
<code>orderFailed</code> method in our <code>OrderService</code>. So the caller 
receives an Exchange with the payload <code>Order ERROR</code> and a 
<code>orderid=failed</code> in a header.</p><h3 
id="ExceptionClause-UsinghandledwithSpringDSL">Using handled with Spring 
DSL</h3><p>The same route as above in Spring DSL:</p><div class="code panel 
pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+</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&#160;<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[
 &lt;!-- setup our error handler as the deal letter channel --&gt;
 &lt;bean id=&quot;errorHandler&quot; 
class=&quot;org.apache.camel.builder.DeadLetterChannelBuilder&quot;&gt;
@@ -328,7 +337,7 @@ public static class OrderFailedException
 
 &lt;/camelContext&gt;
 ]]></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">
+</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.
@@ -344,7 +353,7 @@ 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 excepetion 
message:<div class="code panel pdl" style="border-width: 1px;"><div 
class="codeContent panelContent pdl">
+</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
@@ -353,10 +362,10 @@ onException(MyFunctionalException.class)
         .handled(true)
         .transform().simple(&quot;Error reported: ${exception.message} - 
cannot process this message.&quot;);
 ]]></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>handle</strong> and <strong>continue</strong> routing in the 
original route as if the exception did not occur.</p><p>For instance to just 
ignore and continue if the <code>IDontCareException</code> was thrown we can do 
this:</p><div class="code panel pdl" style="border-width: 1px;"><div 
class="codeContent panelContent pdl">
+</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&#160;<strong><code>handle</code></strong> 
and&#160;<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 <code>try ... 
catch</code> block around each step and then just ignore the exception.<br 
clear="none"> 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 IllegalArgumentException 
as we just want to continue routing.</p><div class="code panel pdl" 
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+</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&#160;<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
@@ -387,26 +396,27 @@ public void configure() throws Exception
 
 &lt;/camelContext&gt;
 ]]></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 <code>onException</code> 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 <code>onException</code> it will route that 
route first, before it will continue routing in the original route.</p><h3 
id="ExceptionClause-UsinguseOriginalMessage">Using 
useOriginalMessage</h3><p><strong>Available as of Camel 2.0</strong><br 
clear="none"> The opt
 ion <strong>useOriginalMessage</strong> is used for routing the original input 
body instead of the current body that potential is modified during 
routing.</p><p>For instance 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(&quot;jms:queue:order:input&quot;)
-       .to(&quot;bean:validateOrder&quot;);
-       .to(&quot;bean:transformOrder&quot;)
-       .to(&quot;bean:handleOrder&quot;);
-]]></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>onException</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 transformOrder 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>useOriginalMessage</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
-    onException(MyOrderException.class)
-       .useOriginalMessage().handled(true)
-       .to(&quot;jms:queue:order:failed&quot;);
-]]></script>
-</div></div><p>Then the messages routed to the 
<code>jms:queue:order:failed</code> 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">useOriginalMessage with 
Spring DSL</h4><p>The <strong>useOriginalMessage</strong> option is defined as 
a boolean attribute on the &lt;onException&gt; 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[    &lt;onException 
useOriginalMessage=&quot;true&quot;&gt;
-        &lt;exception&gt;com.mycompany.MyOrderException&lt;/exception&gt;
-        &lt;handled&gt;&lt;constant&gt;true&lt;/constant&gt;&lt;/handled&gt;
-        &lt;to uri=&quot;jms:queue:order:failed&quot;/&gt;
-    &lt;/onException&gt;
+</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&#160;<code>useOriginalMessage</code></h3><p><strong>Availab
 le as of Camel 2.0</strong><br clear="none"> The 
option&#160;<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(&quot;jms:queue:order:input&quot;)
+  .to(&quot;bean:validateOrder&quot;);
+  .to(&quot;bean:transformOrder&quot;)
+  .to(&quot;bean:handleOrder&quot;);
+]]></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&#160;<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
+onException(MyOrderException.class)
+  .useOriginalMessage()
+  .handled(true)
+  .to(&quot;jms:queue:order:failed&quot;);
+]]></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&#160;<strong><code>useOriginalMessage</code></strong> option is 
defined as a boolean attribute on 
the&#160;<strong><code>&lt;onException&gt;</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[&lt;onException 
useOriginalMessage=&quot;true&quot;&gt;
+  &lt;exception&gt;com.mycompany.MyOrderException&lt;/exception&gt;
+  &lt;handled&gt;&lt;constant&gt;true&lt;/constant&gt;&lt;/handled&gt;
+  &lt;to uri=&quot;jms:queue:order:failed&quot;/&gt;
+&lt;/onException&gt;
 ]]></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">
+</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
@@ -429,7 +439,7 @@ from(&quot;direct:start&quot;)
     .end()
     .to(&quot;mock:result&quot;);
 ]]></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>onException</strong> route with <code>.end()</code> 
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">
+</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&#160;<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(&quot;mock:error&quot;));
@@ -455,7 +465,7 @@ from(&quot;direct:start&quot;)
     .end()
     .to(&quot;mock:result&quot;);
 ]]></script>
-</div></div>And now it gets complex as we combine global and route specific 
exception policies as we introduce a 2nd route in the sample:<div class="code 
panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+</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
@@ -479,7 +489,7 @@ from(&quot;direct:start2&quot;)
     .to(&quot;bean:myServiceBean&quot;)
     .to(&quot;mock:result&quot;);
 ]]></script>
-</div></div>Notice that we can define the same exception MyFunctionalException 
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 onException 
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">
+</div></div>Notice that we can define the same 
exception&#160;<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&#160;<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(&quot;direct:start3&quot;)
     // route specific error handler that is different than the global error 
handler
@@ -494,7 +504,7 @@ from(&quot;direct:start3&quot;)
     .to(&quot;bean:myServiceBean&quot;)
     .to(&quot;mock:result&quot;);
 ]]></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 <code>MyTechnicalException</code> is thrown 
then it's the global exception policy that is selected.</p></div></div><h3 
id="ExceptionClause-UsingfinegrainedselectionusingonWhenpredicate">Using fine 
grained selection using onWhen 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:</p><div class="code panel pdl" 
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+</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&#160;<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(&quot;mock:error&quot;).redeliveryDelay(0).maximumRedeliveries(3));
@@ -514,7 +524,7 @@ public void configure() throws Exception
         .maximumRedeliveries(2)
         .to(ERROR_QUEUE);
 ]]></script>
-</div></div>In the sample above we have two onException's defined. The first 
has an <strong>onWhen</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 2nd clause is a for coarse 
gained selection to select the same exception being thrown but when the 
expression is evaluated to false. <strong>Notice:</strong> this is not 
required, if the 2nd clause is omitted, then the default error handler will 
kick in.<h3 id="ExceptionClause-UsingonRedeliveryprocessor">Using onRedelivery 
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>onRedelivery</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.h
 tml">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>onRedelivery</strong>.</p><p>In the code below we want 
to do some custom code before redelivering any IOException. So we configure an 
<strong>onException</strong> for the IOException and set the 
<strong>onRedelivery</strong> to use our custom processor:</p><div class="code 
panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+</div></div>In the sample above we have two 
<strong><code>onException</code></strong>'s defined. The first has 
an&#160;<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&#160;<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&#160;<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&#160;<strong><code>onException</code></strong> for 
the&#160;<strong><code>IOException</code></strong> and set 
the&#160;<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
@@ -537,20 +547,23 @@ public static class MyIORedeliverProcess
     }
 }
 ]]></script>
-</div></div><h4 id="ExceptionClause-UsingonRedeliveryinSpringDSL">Using 
onRedelivery in Spring DSL</h4><p>In Spring DSL you need to use the 
<strong>onRedeliveryRef</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">
+</div></div><h4 
id="ExceptionClause-UsingonRedeliveryinSpringDSL">Using&#160;<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[
 &lt;onException onRedeliveryRef=&quot;myIORedeliverProcessor&quot;&gt;
     &lt;exception&gt;java.io.IOException&lt;/exception&gt;
 &lt;/onException&gt;
 ]]></script>
-</div></div>And our processor is just a regular spring bean (we use $ 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">
+</div></div>And our processor is just a regular spring bean (we 
use&#160;<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[
 &lt;bean id=&quot;myRedeliveryProcessor&quot;
       
class=&quot;org.apache.camel.processor.DeadLetterChannelOnExceptionOnRedeliveryTest$MyRedeliverProcessor&quot;/&gt;
 ]]></script>
-</div></div><h3 id="ExceptionClause-UsingonExceptionOccurredprocessor">Using 
onExceptionOccurred 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>&#160;has support 
for&#160;<strong>onExceptionOccurred</strong>&#160;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 onRedelivery processor and 
onExceptionOccurred 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 onExceptionOccurred processor is always invoked right 
after the exception was thrown, and also if redelivery ha
 s been disabled.&#160;<strong>Important:&#160;</strong>Any new exceptions 
thrown from the onExceptionOccurred processor is logged as WARN and ignored, to 
not override the existing exception.&#160;</p><p>In the code below we want to 
do some custom logging when an exception happened So we configure 
an&#160;<strong>onExceptionOcurred</strong>&#160;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().maximumRedeliveries(3).redeliveryDelay(5000).onExceptionOccurred(myProcessor));]]></script>
-</div></div><h4 id="ExceptionClause-UsingonRedeliveryinSpringDSL.1">Using 
onRedelivery in Spring DSL</h4><p>In Spring DSL you need to use 
the&#160;<strong>onExceptionOccurredRef</strong>&#160;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">
+</div></div><h3 
id="ExceptionClause-UsingonExceptionOccurredProcessor">Using&#160;<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>&#160;has 
support for&#160;<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&#160;<strong><code>onRedelivery</code></strong> processor 
and&#160;<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&#160;<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:&#160;</strong>Any new exceptions thrown from 
the&#160;<strong><code>onExceptionOccurred</code></strong> processor is logged 
as&#160;<strong><code>WARN</code></strong> and ignored, to not override the 
existing exception.&#160;</p><p>In the code below we want to do some custom 
logging when an exception happened. Therefore we configure 
an&#160;<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()
+              .maximumRedeliveries(3)
+              .redeliveryDelay(5000)
+              .onExceptionOccurred(myProcessor));]]></script>
+</div></div><h4 
id="ExceptionClause-UsingonRedeliveryinSpringDSL.1">Using&#160;<code>onRedelivery</code>
 in Spring DSL</h4><p>In Spring DSL you need to use 
the&#160;<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[&lt;bean id=&quot;myProcessor&quot; 
class=&quot;com.foo.MyExceptionLoggingProcessor&quot;/&gt;
  
 &lt;camelContext errorHandlerRef=&quot;eh&quot; 
xmlns=&quot;http://camel.apache.org/schema/spring&quot;&gt;
@@ -563,7 +576,7 @@ public static class MyIORedeliverProcess
    ...
 
 &lt;/camelContext&gt;]]></script>
-</div></div><h3 
id="ExceptionClause-UsingfinegrainedretryusingretryWhilepredicate">Using fine 
grained retry using retryWhile 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>retryUntil</strong>. From Camel 2.4 onwards its named 
<strong>retryWhile</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>retryWhile</strong> predicate. Camel will redeliver until the 
predicate returns false.<br clear="none"> This is demonstrated in the sample 
below:</p><div class="code panel pdl" style="border-width: 1px;"><div 
class="codeContent panelContent
  pdl">
+</div></div><h3 
id="ExceptionClause-UsingFineGrainedRetryUsingretryWhilePredicate">Using Fine 
Grained Retry Using&#160;<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&#160;<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&#160;<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
@@ -574,7 +587,7 @@ onException(MyFunctionalException.class)
         .handled(true)
         .transform().constant(&quot;Sorry&quot;);
 ]]></script>
-</div></div>Where the bean myRetryHandler is computing if we should retry or 
not:<div class="code panel pdl" style="border-width: 1px;"><div 
class="codeContent panelContent pdl">
+</div></div>Where the bean&#160;<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 {
 
@@ -591,7 +604,7 @@ public class MyRetryBean {
     }
 }
 ]]></script>
-</div></div><h3 id="ExceptionClause-UsingcustomExceptionPolicyStrategy">Using 
custom ExceptionPolicyStrategy</h3><p><strong>Available in Camel 
1.4</strong></p><p>The default <a shape="rect" class="external-link" 
href="http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/processor/exceptionpolicy/ExceptionPolicyStrategy.html";>ExceptionPolicyStrategy</a>
 in Camel should be sufficient in nearly all use-cases (see section <em>How 
does Camel select which clause should handle a given thrown Exception</em>). 
However if you need to use your own this can be configued as the sample below 
illustrates:</p><div class="code panel pdl" style="border-width: 1px;"><div 
class="codeContent panelContent pdl">
+</div></div><h3 id="ExceptionClause-UsingCustomExceptionPolicyStrategy">Using 
Custom&#160;<code>ExceptionPolicyStrategy</code></h3><p><strong>Available in 
Camel 1.4</strong></p><p>The default <a shape="rect" class="external-link" 
href="http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/processor/exceptionpolicy/ExceptionPolicyStrategy.html";>ExceptionPolicyStrategy</a>
 in Camel should be sufficient in nearly all use-cases (see section <em>How 
does Camel select which clause should handle a given thrown Exception</em>). 
However, if you need to use your own this can be configured as the sample below 
illustrates:</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 {
     // configure the error handler to use my policy instead of the default 
from Camel
@@ -607,7 +620,7 @@ public void configure() throws Exception
         .setHeader(MESSAGE_INFO, constant(&quot;Damm a Camel exception&quot;))
         .to(ERROR_QUEUE);
 ]]></script>
-</div></div>Using our own strategy <strong>MyPolicy</strong> we can change the 
default behavior of Camel with our own code to resolve which <a shape="rect" 
class="external-link" 
href="http://camel.apache.org/maven/camel-core/apidocs/org/apache/camel/model/ExceptionType.html";>ExceptionType</a>
 from above should be handling the given thrown exception.<div class="code 
panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+</div></div>Using our own strategy <strong><code>MyPolicy</code></strong> we 
can change the default behavior of Camel with our own code to resolve which <a 
shape="rect" class="external-link" 
href="http://camel.apache.org/maven/camel-core/apidocs/org/apache/camel/model/ExceptionType.html";>ExceptionType</a>
 from above should be handling the given thrown 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[
 public static class MyPolicy implements ExceptionPolicyStrategy {
 
@@ -620,7 +633,7 @@ public static class MyPolicy implements
     }
 }
 ]]></script>
-</div></div><h3 id="ExceptionClause-UsingtheexceptionclauseinSpringDSL">Using 
the exception clause in Spring DSL</h3><p>You can use all of the above 
mentioned exception clause features in the Spring DSL as well. Here are a few 
examples:</p><ul><li><p>Global scoped - <strong>Available in Camel 
2.0</strong></p><div class="code panel pdl" style="border-width: 1px;"><div 
class="codeContent panelContent pdl">
+</div></div><h3 id="ExceptionClause-UsingtheExceptionClauseinSpringDSL">Using 
the Exception Clause in Spring DSL</h3><p>You can use all of the above 
mentioned exception clause features in the Spring DSL as well. Here are a few 
examples:</p><ul><li><p>Global scoped - <strong>Available in Camel 
2.0</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[
 &lt;!-- setup our error handler as the deal letter channel --&gt;
 &lt;bean id=&quot;errorHandler&quot; 
class=&quot;org.apache.camel.builder.DeadLetterChannelBuilder&quot;&gt;

Modified: websites/production/camel/content/jetty.html
==============================================================================
--- websites/production/camel/content/jetty.html (original)
+++ websites/production/camel/content/jetty.html Tue Oct 18 17:19:28 2016
@@ -190,7 +190,7 @@ jettyComponent.setSslContextParameters(s
 </div></div><h5 id="Jetty-ConfiguringJettyDirectly">Configuring Jetty 
Directly</h5><p>Jetty provides SSL support out of the box. To enable Jetty to 
run in SSL mode, simply format the URI using the 
<strong><code>https://</code></strong> 
prefix.</p><p><strong>Example</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[&lt;from 
uri=&quot;jetty:https://0.0.0.0/myapp/myservice/&quot;/&gt;
 ]]></script>
-</div></div><p>Jetty also needs to know where to load your keystore from and 
what passwords to use in order to load the correct SSL certificate. Set the 
following JVM System Properties:</p><p><strong>Before Camel 
2.3</strong>:</p><div class="table-wrap"><table 
class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1" 
class="confluenceTh">Property</th><th colspan="1" rowspan="1" 
class="confluenceTh">Description</th></tr><tr><td colspan="1" rowspan="1" 
class="confluenceTd"><code>jetty.ssl.keystore</code></td><td colspan="1" 
rowspan="1" class="confluenceTd">Specifies the location of the 
Java&#160;<strong><code>keystore</code></strong> file, which contains the Jetty 
server's own&#160;<strong><code>X.509</code></strong> certificate in a <em>key 
entry</em>. A key entry stores the&#160;<strong><code>X.509</code></strong> 
certificate (effectively, the <em>public key</em>) and also its associated 
private key.</td></tr><tr><td colspan="1" rowspan="1" 
class="confluenceTd"><code>jetty.ssl.
 password</code></td><td colspan="1" rowspan="1" class="confluenceTd">The store 
password, which is required to access 
the&#160;<strong><code>keystore</code></strong> file (this is the same password 
that is supplied to the <strong><code>keystore</code></strong> command's 
<strong><code>-storepass</code></strong> option).</td></tr><tr><td colspan="1" 
rowspan="1" class="confluenceTd"><code>jetty.ssl.keypassword</code></td><td 
colspan="1" rowspan="1" class="confluenceTd">The key password, which is used to 
access the certificate's key entry in 
the&#160;<strong><code>keystore</code></strong> (this is the same password that 
is supplied to the <strong><code>keystore</code></strong> command's 
<strong><code>-keypass</code></strong> 
option).</td></tr></tbody></table></div><p>&#160;</p><p><strong>From Camel 
2.3</strong>:</p><div class="table-wrap"><table 
class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1" 
class="confluenceTh">&#160;</th><th colspan="1" rowspan="1" 
class="confluenceTh">
 &#160;</th></tr><tr><td colspan="1" rowspan="1" 
class="confluenceTd"><code>org.eclipse.jetty.ssl.keystore</code></td><td 
colspan="1" rowspan="1" class="confluenceTd">Specifies the location of the 
Java&#160;<strong><code>keystore</code></strong> file, which contains the Jetty 
server's own&#160;<strong><code>X.509</code></strong> certificate in a <em>key 
entry</em>. A key entry stores the&#160;<strong><code>X.509</code></strong> 
certificate (effectively, the <em>public key</em>) and also its associated 
private key.</td></tr><tr><td colspan="1" rowspan="1" 
class="confluenceTd"><code>org.eclipse.jetty.ssl.password</code></td><td 
colspan="1" rowspan="1" class="confluenceTd">The store password, which is 
required to access the&#160;<strong><code>keystore</code></strong> file (this 
is the same password that is supplied to 
the&#160;<strong><code>keystore</code></strong> 
command's&#160;<strong><code>keystore</code></strong> option).</td></tr><tr><td 
colspan="1" rowspan="1" class="confluenceTd
 "><code>org.eclipse.jetty.ssl.keypassword</code></td><td colspan="1" 
rowspan="1" class="confluenceTd">The key password, which is used to access the 
certificate's key entry in the&#160;<strong><code>keystore</code></strong> 
(this is the same password that is supplied to 
the&#160;<strong><code>keystore</code></strong> 
command's&#160;<strong><code>keystore</code></strong> 
option).</td></tr></tbody></table></div><p>For details of how to configure SSL 
on a Jetty endpoint, read the following <a shape="rect" class="external-link" 
href="http://www.eclipse.org/jetty/documentation/current/configuring-ssl.html"; 
rel="nofollow">Jetty documentation</a>.</p><p>Some SSL properties aren't 
exposed directly by Camel, however Camel does expose the underlying 
<strong><code>SslSocketConnector</code></strong>, which will allow you to set 
properties like&#160;<strong><code>needClientAuth</code></strong> for mutual 
authentication requiring a client certificate 
or&#160;<strong><code>wantClientAuth</code></st
 rong> for mutual authentication where a client doesn't need a certificate but 
can have one.</p><p>There's a slight difference between the various Camel 
versions:</p><p><strong>Up to Camel 2.2</strong></p><div class="code panel pdl" 
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+</div></div><p>Jetty also needs to know where to load your keystore from and 
what passwords to use in order to load the correct SSL certificate. Set the 
following JVM System Properties:</p><p><strong>Before Camel 
2.3</strong>:</p><div class="table-wrap"><table 
class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1" 
class="confluenceTh">Property</th><th colspan="1" rowspan="1" 
class="confluenceTh">Description</th></tr><tr><td colspan="1" rowspan="1" 
class="confluenceTd"><code>jetty.ssl.keystore</code></td><td colspan="1" 
rowspan="1" class="confluenceTd">Specifies the location of the 
Java&#160;<strong><code>keystore</code></strong> file, which contains the Jetty 
server's own&#160;<strong><code>X.509</code></strong> certificate in a <em>key 
entry</em>. A key entry stores the&#160;<strong><code>X.509</code></strong> 
certificate (effectively, the <em>public key</em>) and also its associated 
private key.</td></tr><tr><td colspan="1" rowspan="1" 
class="confluenceTd"><code>jetty.ssl.
 password</code></td><td colspan="1" rowspan="1" class="confluenceTd">The store 
password, which is required to access 
the&#160;<strong><code>keystore</code></strong> file (this is the same password 
that is supplied to the <strong><code>keystore</code></strong> command's 
<strong><code>-storepass</code></strong> option).</td></tr><tr><td colspan="1" 
rowspan="1" class="confluenceTd"><code>jetty.ssl.keypassword</code></td><td 
colspan="1" rowspan="1" class="confluenceTd">The key password, which is used to 
access the certificate's key entry in 
the&#160;<strong><code>keystore</code></strong> (this is the same password that 
is supplied to the <strong><code>keystore</code></strong> command's 
<strong><code>-keypass</code></strong> 
option).</td></tr></tbody></table></div><p>&#160;</p><p><strong>From Camel 
2.3</strong>:</p><div class="table-wrap"><table 
class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1" 
class="confluenceTh">Property</th><th colspan="1" rowspan="1" 
class="confluenceTh
 ">Description</th></tr><tr><td colspan="1" rowspan="1" 
class="confluenceTd"><code>org.eclipse.jetty.ssl.keystore</code></td><td 
colspan="1" rowspan="1" class="confluenceTd">Specifies the location of the 
Java&#160;<strong><code>keystore</code></strong> file, which contains the Jetty 
server's own&#160;<strong><code>X.509</code></strong> certificate in a <em>key 
entry</em>. A key entry stores the&#160;<strong><code>X.509</code></strong> 
certificate (effectively, the <em>public key</em>) and also its associated 
private key.</td></tr><tr><td colspan="1" rowspan="1" 
class="confluenceTd"><code>org.eclipse.jetty.ssl.password</code></td><td 
colspan="1" rowspan="1" class="confluenceTd">The store password, which is 
required to access the&#160;<strong><code>keystore</code></strong> file (this 
is the same password that is supplied to 
the&#160;<strong><code>keystore</code></strong> 
command's&#160;<strong><code>keystore</code></strong> option).</td></tr><tr><td 
colspan="1" rowspan="1" class="confl
 uenceTd"><code>org.eclipse.jetty.ssl.keypassword</code></td><td colspan="1" 
rowspan="1" class="confluenceTd">The key password, which is used to access the 
certificate's key entry in the&#160;<strong><code>keystore</code></strong> 
(this is the same password that is supplied to 
the&#160;<strong><code>keystore</code></strong> 
command's&#160;<strong><code>keystore</code></strong> 
option).</td></tr></tbody></table></div><p>For details of how to configure SSL 
on a Jetty endpoint, read the following <a shape="rect" class="external-link" 
href="http://www.eclipse.org/jetty/documentation/current/configuring-ssl.html"; 
rel="nofollow">Jetty documentation</a>.</p><p>Some SSL properties aren't 
exposed directly by Camel, however Camel does expose the underlying 
<strong><code>SslSocketConnector</code></strong>, which will allow you to set 
properties like&#160;<strong><code>needClientAuth</code></strong> for mutual 
authentication requiring a client certificate 
or&#160;<strong><code>wantClientAuth</co
 de></strong> for mutual authentication where a client doesn't need a 
certificate but can have one.</p><p>There's a slight difference between the 
various Camel versions:</p><p><strong>Up to Camel 2.2</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[&lt;bean id=&quot;jetty&quot; 
class=&quot;org.apache.camel.component.jetty.JettyHttpComponent&quot;&gt;
     &lt;property name=&quot;sslSocketConnectors&quot;&gt;
         &lt;map&gt;


Reply via email to