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-k.git
The following commit(s) were added to refs/heads/master by this push:
new 7977301 Fixed WARN in doc when generating website
7977301 is described below
commit 79773017133da8640da6963de6350cef3c12a296
Author: Claus Ibsen <claus.ib...@gmail.com>
AuthorDate: Mon Mar 29 06:18:33 2021 +0200
Fixed WARN in doc when generating website
---
docs/modules/ROOT/pages/kamelets/kamelets-dev.adoc | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/docs/modules/ROOT/pages/kamelets/kamelets-dev.adoc
b/docs/modules/ROOT/pages/kamelets/kamelets-dev.adoc
index 2ec9829..844ec08 100644
--- a/docs/modules/ROOT/pages/kamelets/kamelets-dev.adoc
+++ b/docs/modules/ROOT/pages/kamelets/kamelets-dev.adoc
@@ -115,7 +115,7 @@ spec:
<2> Some endpoint parameters are just mapped 1-1
<3> The Camel component `consumerKey` is named `apiKey` to reflect the actual
name in the Twitter developer portal
<4> The Camel Twitter component generates Java objects, so we marshal them to
JSON
-<4> A Source Kamelet sends data to the special endpoint "kamelet:sink", that
will be replaced at runtime by a different target
+<5> A Source Kamelet sends data to the special endpoint "kamelet:sink", that
will be replaced at runtime by a different target
The YAML route template above just uses the `twitter-search` component to do
searches on Twitter. We added a marshalling step to JSON
because the output of a Kamelet needs always to be something that can be
transferred over the wire.
@@ -453,8 +453,8 @@ NOTE: We've truncated the list of "features" to just the
first one, but it conta
Since the integration above produces useful data, its route could be
technically used to build a source Kamelet, but there are a few problems we may
want to address before publishing it:
1. It produces a lot of data (10762 events, last 30 days by default). We may
want to start emitting events of the last e.g. 2 hours by default for this use
case: we can add a filter on the query to accomplish this.
-1. It produces a collection of features (earthquake events), while you may
want to push to the destination the individual features. We can use Camel's
built-in `split` and `jsonpath` support to split the collection into separate
entries.
-1. It continuously produces the same data: i.e. just wait another 10 seconds
and you'll get the same data again and again (with a shift of 10 seconds over
the last 30 days). A good approach here is to try to filter out duplicates at
the source
+2. It produces a collection of features (earthquake events), while you may
want to push to the destination the individual features. We can use Camel's
built-in `split` and `jsonpath` support to split the collection into separate
entries.
+3. It continuously produces the same data: i.e. just wait another 10 seconds
and you'll get the same data again and again (with a shift of 10 seconds over
the last 30 days). A good approach here is to try to filter out duplicates at
the source
as much as possible. We can think to store the time when the last update has
been generated by the server and use it in subsequent queries to only obtain
new events.
This will not guarantee an "exactly once" semantics, because e.g. if the
integration is restarted it will lose the in-memory state and start from the
beginning,
but it prevents sending an high amount of redundant data if the integration is
kept alive.
@@ -759,7 +759,7 @@ spec:
----
<1> The definition part starts with general information about the Kamelet
<2> Definition of the "period" parameter (used with the `{{period}}`
placeholder in the route)
-<2> Definition of the "lookAhead" parameter
+<3> Definition of the "lookAhead" parameter
=== Step 7: add metadata and sugar
