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[ <bean
id="myRedeliveryPolicy"
class="org.apache.camel.processor.RedeliveryPolicy">
<property name="maximumRedeliveries"
value="${myprop.max}"/>
</bean>
@@ -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("direct:start")
// this is the destination if the order is OK
.to("mock:result");
]]></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[
<!-- setup our error handler as the deal letter channel -->
<bean id="errorHandler"
class="org.apache.camel.builder.DeadLetterChannelBuilder">
@@ -336,7 +336,7 @@ onException(MyFunctionalException.class)
.handled(true)
.transform().constant("Sorry");
]]></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("mock:result");
}
]]></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[
<camelContext xmlns="http://camel.apache.org/schema/spring">
@@ -429,7 +429,7 @@ from("direct:start")
.end()
.to("mock:result");
]]></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("mock:error"));
@@ -455,7 +455,7 @@ from("direct:start")
.end()
.to("mock:result");
]]></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("direct:start2")
.to("bean:myServiceBean")
.to("mock:result");
]]></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("direct:start3")
// 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
<exception>java.io.IOException</exception>
</onException>
]]></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[
<bean id="myRedeliveryProcessor"
class="org.apache.camel.processor.DeadLetterChannelOnExceptionOnRedeliveryTest$MyRedeliverProcessor"/>
@@ -559,7 +559,7 @@ onException(MyFunctionalException.class)
.handled(true)
.transform().constant("Sorry");
]]></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("Damm a Camel exception"))
.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"><