This is an automated email from the ASF dual-hosted git repository.
orpiske pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/camel.git
commit 42e966705c963b3b1d3ee38662be84110554105a
Author: Otavio R. Piske <angusyo...@gmail.com>
AuthorDate: Sun Feb 25 14:27:19 2024 +0100
CAMEL-20459: minor documentation tweaks for the dead letter channel EIP.
Signed-off-by: Otavio R. Piske <angusyo...@gmail.com>
---
.../modules/eips/pages/dead-letter-channel.adoc | 54 +++++++++++++++++++---
1 file changed, 47 insertions(+), 7 deletions(-)
diff --git
a/core/camel-core-engine/src/main/docs/modules/eips/pages/dead-letter-channel.adoc
b/core/camel-core-engine/src/main/docs/modules/eips/pages/dead-letter-channel.adoc
index 90c33144433..3bcf96669cb 100644
---
a/core/camel-core-engine/src/main/docs/modules/eips/pages/dead-letter-channel.adoc
+++
b/core/camel-core-engine/src/main/docs/modules/eips/pages/dead-letter-channel.adoc
@@ -144,14 +144,18 @@ The exchange is then complete, and from the client point
of view, the message is
For instance, configuring the dead letter channel as:
+[tabs]
+====
+Java::
++
[source,java]
----
errorHandler(deadLetterChannel("jms:queue:dead")
.maximumRedeliveries(3).redeliveryDelay(5000));
----
-And in XML:
-
+XML::
++
[source,xml]
----
<errorHandler id="myErrorHandler" type="DeadLetterChannel"
@@ -160,6 +164,8 @@ And in XML:
</errorHandler>
----
+====
+
The Dead Letter error handler will clear the caused exception
(`setException(null)`), by moving the caused exception to a property on the
xref:manual::exchange.adoc[Exchange], with the key `Exchange.EXCEPTION_CAUGHT`.
Then the xref:manual::exchange.adoc[Exchange]
is moved to the `jms:queue:dead` destination, and the client will not notice
the failure.
@@ -194,6 +200,11 @@ There is also a *useOriginalBody* option, which only keeps
the original message
not change the message headers.
====
+[tabs]
+====
+Java::
++
+
[source,java]
----
// will use the original message (body and headers)
@@ -201,8 +212,10 @@ errorHandler(deadLetterChannel("jms:queue:dead")
.useOriginalMessage().maximumRedeliveries(5).redeliveryDelay(5000);
----
+XML::
++
And in XML, you set `useOriginalMessage=true` on the `<errorHandler>` as shown:
-
++
[source,xml]
----
<errorHandler id="myErrorHandler" type="DeadLetterChannel"
useOriginalMessage="true"
@@ -211,6 +224,8 @@ And in XML, you set `useOriginalMessage=true` on the
`<errorHandler>` as shown:
</errorHandler>
----
+====
+
Then the messages routed to the `jms:queue:dead` 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.
@@ -230,7 +245,12 @@ When the Dead Letter Channel is doing redelivery, it's
possible to configure a x
executed just _before_ every redelivery attempt.
This can be used for situations where you need to alter the message before
it's redelivered.
-For example, in Java DSL you can do:
+For example, you can do:
+
+[tabs]
+====
+Java::
++
[source,java]
----
@@ -239,8 +259,10 @@ errorHandler(deadLetterChannel("jms:queue:dead")
.onRedeliver(new MyOnRedeliveryProcessor());
----
+XML::
++
And in XML DSL, you specify a bean id via `onRedeliveryRef` on the
`<errorHandler>` as shown:
-
++
[source,xml]
----
<bean id="myRedeliveryProcessor" class="com.foo.MyRedeliveryProcessor"/>
@@ -251,6 +273,8 @@ And in XML DSL, you specify a bean id via `onRedeliveryRef`
on the `<errorHandle
</errorHandler>
----
+====
+
TIP: Camel also supports xref:manual::exception-clause.adoc[onException] to
use `onRedeliver`.
This means you can do special on redelivery for different exceptions, as
opposed to `onRedelivery` set on
Dead Letter Channel (or xref:manual::defaulterrorhandler.adoc[Default Error
Handler]) can be viewed as global scoped.
@@ -275,13 +299,20 @@ public static class MyPrepareProcessor implements
Processor {
Then configure the error handler to use the processor as follows:
+[tabs]
+====
+Java::
++
+
[source,java]
----
errorHandler(deadLetterChannel("jms:dead").onPrepareFailure(new
MyPrepareProcessor()));
----
+XML::
++
Configuring this from Spring XML is done with the `onPrepareFailureRef` to
refer to the processor as a `<bean>` as shown:
-
++
[source,xml]
----
<bean id="myPrepare"
@@ -290,6 +321,8 @@ Configuring this from Spring XML is done with the
`onPrepareFailureRef` to refer
<errorHandler id="dlc" type="DeadLetterChannel" deadLetterUri="jms:dead"
onPrepareFailureRef="myPrepare"/>
----
+====
+
=== Calling a processor when an exception occurred
With the `onExceptionOccurred` you can call a custom processor right after an
exception was thrown,
@@ -313,19 +346,26 @@ public static class OnErrorLogger implements Processor {
You can then configure the Dead Letter Channel to use this as shown:
+[tabs]
+====
+Java::
++
[source,java]
----
errorHandler(deadLetterChannel("jms:dead").onExceptionOccurred(new
OnErrorLogger()));
----
+XML::
++
Configuring this from Spring XML is done with the `onExceptionOccurredRef` to
refer to the processor as a `<bean>` as shown:
-
++
[source,xml]
----
<bean id="myErrorLogger" class="com.foo.OnErrorLogger"/>
<errorHandler id="dlc" type="DeadLetterChannel" deadLetterUri="jms:dead"
onExceptionOccurredRef="myErrorLogger"/>
----
+====
=== Redeliver Delay Pattern
