camel-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r963133 - in /websites/production/camel/content: cache/main.pageCache exception-clause.html
Date Wed, 26 Aug 2015 13:19:34 GMT
Author: buildbot
Date: Wed Aug 26 13:19:33 2015
New Revision: 963133

Log:
Production update by buildbot for camel

Modified:
    websites/production/camel/content/cache/main.pageCache
    websites/production/camel/content/exception-clause.html

Modified: websites/production/camel/content/cache/main.pageCache
==============================================================================
Binary files - no diff available.

Modified: websites/production/camel/content/exception-clause.html
==============================================================================
--- websites/production/camel/content/exception-clause.html (original)
+++ websites/production/camel/content/exception-clause.html Wed Aug 26 13:19:33 2015
@@ -155,7 +155,7 @@ onException(FileNotFoundException.class)
  .process("processor2") // <--- throws a ConnectException
 .to("mock:theEnd")
 ]]></script>
-</div></div><p>Will retry from <strong>processor2</strong>
- not the complete route.</p><h4 id="ExceptionClause-ReusingReliveryPolicy">Reusing
ReliveryPolicy</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">
+</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;
@@ -186,7 +186,7 @@ onException(FileNotFoundException.class)
 // when this exception occur we want it to be processed by our processor
 onException(MyFunctionalException.class).process(new MyFunctionFailureHandler()).stop();
 ]]></script>
-</div></div><p>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.</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
+</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">
 <script class="brush: java; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[
 public static class MyFunctionFailureHandler implements Processor {
 
@@ -204,7 +204,7 @@ public static class MyFunctionFailureHan
     }
 }
 ]]></script>
-</div></div><p>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-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
  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 <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">
+</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);
 ]]></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">
@@ -231,7 +231,7 @@ from(&quot;direct:start&quot;)
     // this is the destination if the order is OK
     .to(&quot;mock:result&quot;);
 ]]></script>
-</div></div><p>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:</p><div class="code panel pdl" style="border-width:
1px;"><div class="codeContent panelContent pdl">
+</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
@@ -272,7 +272,7 @@ public static class OrderService {
     }
 }
 ]]></script>
-</div></div><p>And finally the exception that is being thrown is just a
regular exception:</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
+</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
@@ -287,7 +287,7 @@ public static class OrderFailedException
     
 }
 ]]></script>
-</div></div><p>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 <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 <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">
 <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;
@@ -336,7 +336,7 @@ onException(MyFunctionalException.class)
         .handled(true)
         .transform().constant(&quot;Sorry&quot;);
 ]]></script>
-</div></div><p>We modify the sample slightly to return the original caused
exception message instead of the fixed text Sorry:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+</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
@@ -344,7 +344,7 @@ onException(MyFunctionalException.class)
         .handled(true)
         .transform(exceptionMessage());
 ]]></script>
-</div></div><p>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:</p><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 excepetion 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
@@ -368,7 +368,7 @@ public void configure() throws Exception
         .to(&quot;mock:result&quot;);
 }
 ]]></script>
-</div></div><p>And the same example in Spring XML:</p><div class="code
panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+</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[
 &lt;camelContext xmlns=&quot;http://camel.apache.org/schema/spring&quot;&gt;
 
@@ -429,7 +429,7 @@ from(&quot;direct:start&quot;)
     .end()
     .to(&quot;mock:result&quot;);
 ]]></script>
-</div></div><p>In the next sample we change the global exception policies
to be pure route specific.</p><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><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 <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">
 <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 +455,7 @@ from(&quot;direct:start&quot;)
     .end()
     .to(&quot;mock:result&quot;);
 ]]></script>
-</div></div><p>And now it gets complex as we combine global and route specific
exception policies as we introduce a 2nd route in the sample:</p><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 2nd 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 +479,7 @@ from(&quot;direct:start2&quot;)
     .to(&quot;bean:myServiceBean&quot;)
     .to(&quot;mock:result&quot;);
 ]]></script>
-</div></div><p>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><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 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">
 <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
@@ -514,7 +514,7 @@ public void configure() throws Exception
         .maximumRedeliveries(2)
         .to(ERROR_QUEUE);
 ]]></script>
-</div></div><p>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.</p><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-c
 lause.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>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 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">
 <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
@@ -523,7 +523,7 @@ onException(IOException.class)
         .maximumRedeliveries(3)
         .onRedelivery(new MyIORedeliverProcessor());
 ]]></script>
-</div></div><p>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.</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent
pdl">
+</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
@@ -543,7 +543,7 @@ public static class MyIORedeliverProcess
     &lt;exception&gt;java.io.IOException&lt;/exception&gt;
 &lt;/onException&gt;
 ]]></script>
-</div></div><p>And our processor is just a regular spring bean (we use
$ for the inner class as this code is based on unit testing)</p><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 $ 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;
@@ -559,7 +559,7 @@ onException(MyFunctionalException.class)
         .handled(true)
         .transform().constant(&quot;Sorry&quot;);
 ]]></script>
-</div></div><p>Where the bean myRetryHandler is computing if we should
retry or not:</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
+</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">
 <script class="brush: java; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[
 public class MyRetryBean {
 
@@ -592,7 +592,7 @@ public void configure() throws Exception
         .setHeader(MESSAGE_INFO, constant(&quot;Damm a Camel exception&quot;))
         .to(ERROR_QUEUE);
 ]]></script>
-</div></div><p>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.</p><div class="code panel
pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+</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">
 <script class="brush: java; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[
 public static class MyPolicy implements ExceptionPolicyStrategy {
 



Mime
View raw message