This is an automated email from the ASF dual-hosted git repository.
davsclaus pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/camel.git
The following commit(s) were added to refs/heads/master by this push:
new 95af9bb Polished
95af9bb is described below
commit 95af9bbe1dc0172d722563710470e78eaa80f209
Author: Claus Ibsen <claus.ib...@gmail.com>
AuthorDate: Fri Sep 11 06:40:06 2020 +0200
Polished
---
.../org/apache/camel/catalog/docs/rabbitmq-component.adoc | 13 +++++++------
.../camel-rabbitmq/src/main/docs/rabbitmq-component.adoc | 13 +++++++------
docs/components/modules/ROOT/pages/rabbitmq-component.adoc | 13 +++++++------
3 files changed, 21 insertions(+), 18 deletions(-)
diff --git
a/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/rabbitmq-component.adoc
b/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/rabbitmq-component.adoc
index e61707f..86085dd 100644
---
a/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/rabbitmq-component.adoc
+++
b/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/rabbitmq-component.adoc
@@ -341,16 +341,17 @@
from("rabbitmq:A?queue=IN&declare=false&autoDelete=false&arg.queue.x-message-ttl
You would think that it would be a straight forward operation. However, if the
source queue has a routing key set in the headers, it will pass down to the
destination and not be overriden with the URI query parameters. Because the
exchange is the same and the routing key is the same, an infinitely growing
loop is created.
-Either make a second exchange for the producer to avoid the headers to pass
through or manually access the exchange headers in a processor and get rid of
the misbehaving key. (Example is written in Kotlin)
+Either make a second exchange for the producer to avoid the headers to pass
through or manually access the exchange headers in a processor and get rid of
the misbehaving key.
-[source,kotlin]
+[source,java]
----
from("rabbitmq:A?queue=IN&declare=false&autoDelete=false&arg.queue.x-message-ttl=20000")
// ...
- .process(Processor { exchange: Exchange ->
- val input = exchange.`in`.body as InputModel
- exchange.`in`.removeHeader("rabbitmq.ROUTING_KEY")
- exchange.`in`.body = OutputModel(...)
+ .process(e -> {
+ InputModel input = e.getMessage().getBody(InputModel.class);
+ e.getMessage().removeHeader("rabbitmq.ROUTING_KEY");
+ OutputModel output = ...
+ e.getMessage().setBody(output);
})
// ...
.to("rabbitmq:A?queue=OUT&routingKey=OUT&declare=false&autoDelete=false&arg.queue.x-message-ttl=20000");
diff --git a/components/camel-rabbitmq/src/main/docs/rabbitmq-component.adoc
b/components/camel-rabbitmq/src/main/docs/rabbitmq-component.adoc
index e61707f..86085dd 100644
--- a/components/camel-rabbitmq/src/main/docs/rabbitmq-component.adoc
+++ b/components/camel-rabbitmq/src/main/docs/rabbitmq-component.adoc
@@ -341,16 +341,17 @@
from("rabbitmq:A?queue=IN&declare=false&autoDelete=false&arg.queue.x-message-ttl
You would think that it would be a straight forward operation. However, if the
source queue has a routing key set in the headers, it will pass down to the
destination and not be overriden with the URI query parameters. Because the
exchange is the same and the routing key is the same, an infinitely growing
loop is created.
-Either make a second exchange for the producer to avoid the headers to pass
through or manually access the exchange headers in a processor and get rid of
the misbehaving key. (Example is written in Kotlin)
+Either make a second exchange for the producer to avoid the headers to pass
through or manually access the exchange headers in a processor and get rid of
the misbehaving key.
-[source,kotlin]
+[source,java]
----
from("rabbitmq:A?queue=IN&declare=false&autoDelete=false&arg.queue.x-message-ttl=20000")
// ...
- .process(Processor { exchange: Exchange ->
- val input = exchange.`in`.body as InputModel
- exchange.`in`.removeHeader("rabbitmq.ROUTING_KEY")
- exchange.`in`.body = OutputModel(...)
+ .process(e -> {
+ InputModel input = e.getMessage().getBody(InputModel.class);
+ e.getMessage().removeHeader("rabbitmq.ROUTING_KEY");
+ OutputModel output = ...
+ e.getMessage().setBody(output);
})
// ...
.to("rabbitmq:A?queue=OUT&routingKey=OUT&declare=false&autoDelete=false&arg.queue.x-message-ttl=20000");
diff --git a/docs/components/modules/ROOT/pages/rabbitmq-component.adoc
b/docs/components/modules/ROOT/pages/rabbitmq-component.adoc
index f34e15a..27fe3dd 100644
--- a/docs/components/modules/ROOT/pages/rabbitmq-component.adoc
+++ b/docs/components/modules/ROOT/pages/rabbitmq-component.adoc
@@ -343,16 +343,17 @@
from("rabbitmq:A?queue=IN&declare=false&autoDelete=false&arg.queue.x-message-ttl
You would think that it would be a straight forward operation. However, if the
source queue has a routing key set in the headers, it will pass down to the
destination and not be overriden with the URI query parameters. Because the
exchange is the same and the routing key is the same, an infinitely growing
loop is created.
-Either make a second exchange for the producer to avoid the headers to pass
through or manually access the exchange headers in a processor and get rid of
the misbehaving key. (Example is written in Kotlin)
+Either make a second exchange for the producer to avoid the headers to pass
through or manually access the exchange headers in a processor and get rid of
the misbehaving key.
-[source,kotlin]
+[source,java]
----
from("rabbitmq:A?queue=IN&declare=false&autoDelete=false&arg.queue.x-message-ttl=20000")
// ...
- .process(Processor { exchange: Exchange ->
- val input = exchange.`in`.body as InputModel
- exchange.`in`.removeHeader("rabbitmq.ROUTING_KEY")
- exchange.`in`.body = OutputModel(...)
+ .process(e -> {
+ InputModel input = e.getMessage().getBody(InputModel.class);
+ e.getMessage().removeHeader("rabbitmq.ROUTING_KEY");
+ OutputModel output = ...
+ e.getMessage().setBody(output);
})
// ...
.to("rabbitmq:A?queue=OUT&routingKey=OUT&declare=false&autoDelete=false&arg.queue.x-message-ttl=20000");
