You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@camel.apache.org by GitBox <gi...@apache.org> on 2021/06/09 08:26:23 UTC
[GitHub] [camel-k] squakez opened a new pull request #2381: doc(kamelets): debugging simple notice
squakez opened a new pull request #2381:
URL: https://github.com/apache/camel-k/pull/2381
<!-- Description -->
<!--
Enter your extended release note in the below block. If the PR requires
additional action from users switching to the new release, include the string
"action required". If no release note is required, write "NONE".
You can (optionally) mark this PR with labels "kind/bug" or "kind/feature" to make sure
the text is added to the right section of the release notes.
-->
**Release Note**
```release-note
NONE
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] astefanutti merged pull request #2381: doc(kamelets): debugging simple notice
Posted by GitBox <gi...@apache.org>.
astefanutti merged pull request #2381:
URL: https://github.com/apache/camel-k/pull/2381
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] astefanutti commented on a change in pull request #2381: doc(kamelets): debugging simple notice
Posted by GitBox <gi...@apache.org>.
astefanutti commented on a change in pull request #2381:
URL: https://github.com/apache/camel-k/pull/2381#discussion_r655152724
##########
File path: docs/modules/ROOT/pages/troubleshooting/debugging.adoc
##########
@@ -52,3 +53,12 @@ image::debugging/remote-debugger.png[Configuration of the remote debugger in Int
Once you configure a debugger, you can **add breakpoints** to various part of the code, then connect the debugger to trigger the JVM startup.
When the debugging session is finished, hitting *ctrl+c* on the terminal where the kamel CLI is running will restore the integration to its original status.
+
+[[debugging-kamelets]]
+== Debugging Kamelets
+
+As we've seen in the previous section, all `Integration` created in Camel K are finally bundled as a Java application, hence, the possibility to debug via JVM debugger. Any `Kamelet` you will be using directly in your `Route` definition or in a `KameletBinding` is automatically converted in a `yaml` route and injected in the Camel Context to be executed. That means that you cannot directly debug a `Kamelet` as you would do with a Java or any other JVM language `Route`.
+
+However, you can troubleshoot individually each `Kamelet` definition by focusing on the specification xref:kamelets/kamelets-user.adoc#_flow[`Flow`]. As an example, you can create a simple https://camel.apache.org/camel-k/latest/languages/yaml.html[`yaml`] test `Route` substituting the `kamelet:source` or `kamelet:sink` with any mock endpoint that can help you debugging the single `Kamelet` flow. Even using a `timer` and a `log` component may be enough for a basic check.
Review comment:
@zregvart @oscerd would you know if there is a way to use `link:` of `xref:` pointing to pages from external modules (https://github.com/apache/camel-k/blob/main/docs/antora.yml#L6), or raw links can be safely used in that case?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] astefanutti commented on a change in pull request #2381: doc(kamelets): debugging simple notice
Posted by GitBox <gi...@apache.org>.
astefanutti commented on a change in pull request #2381:
URL: https://github.com/apache/camel-k/pull/2381#discussion_r649009709
##########
File path: docs/modules/ROOT/pages/troubleshooting/debugging.adoc
##########
@@ -52,3 +53,12 @@ image::debugging/remote-debugger.png[Configuration of the remote debugger in Int
Once you configure a debugger, you can **add breakpoints** to various part of the code, then connect the debugger to trigger the JVM startup.
When the debugging session is finished, hitting *ctrl+c* on the terminal where the kamel CLI is running will restore the integration to its original status.
+
+[[debugging-kamelets]]
+== Debugging Kamelets
+
+As we've seen in the previous section, all `Integration` created in Camel K are finally bundled as a Java application, hence, the possibility to debug via JVM debugger. Any `Kamelet` you will be using directly in your `Route` definition or in a `KameletBinding` is automatically converted in a `yaml` route and injected in the Camel Context to be executed. That means that you cannot directly debug a `Kamelet` as you would do with a Java or any other JVM language `Route`.
+
+However, you can troubleshoot individually each `Kamelet` definition by focusing on the specification xref:kamelets/kamelets-user.adoc#_flow[`Flow`]. As an example, you can create a simple https://camel.apache.org/camel-k/latest/languages/yaml.html[`yaml`] test `Route` substituting the `kamelet:source` or `kamelet:sink` with any mock endpoint that can help you debugging the single `Kamelet` flow. Even using a `timer` and a `log` component may be enough for a basic check.
Review comment:
Should a `link:` or `xref:` be used https://camel.apache.org/camel-k/latest/languages/yaml.html?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] squakez commented on a change in pull request #2381: doc(kamelets): debugging simple notice
Posted by GitBox <gi...@apache.org>.
squakez commented on a change in pull request #2381:
URL: https://github.com/apache/camel-k/pull/2381#discussion_r656018511
##########
File path: docs/modules/ROOT/pages/troubleshooting/debugging.adoc
##########
@@ -52,3 +53,12 @@ image::debugging/remote-debugger.png[Configuration of the remote debugger in Int
Once you configure a debugger, you can **add breakpoints** to various part of the code, then connect the debugger to trigger the JVM startup.
When the debugging session is finished, hitting *ctrl+c* on the terminal where the kamel CLI is running will restore the integration to its original status.
+
+[[debugging-kamelets]]
+== Debugging Kamelets
+
+As we've seen in the previous section, all `Integration` created in Camel K are finally bundled as a Java application, hence, the possibility to debug via JVM debugger. Any `Kamelet` you will be using directly in your `Route` definition or in a `KameletBinding` is automatically converted in a `yaml` route and injected in the Camel Context to be executed. That means that you cannot directly debug a `Kamelet` as you would do with a Java or any other JVM language `Route`.
+
+However, you can troubleshoot individually each `Kamelet` definition by focusing on the specification xref:kamelets/kamelets-user.adoc#_flow[`Flow`]. As an example, you can create a simple https://camel.apache.org/camel-k/latest/languages/yaml.html[`yaml`] test `Route` substituting the `kamelet:source` or `kamelet:sink` with any mock endpoint that can help you debugging the single `Kamelet` flow. Even using a `timer` and a `log` component may be enough for a basic check.
Review comment:
Thanks @zregvart, I've committed your suggestion. @astefanutti I think we can merge it now, thanks!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] heiko-braun commented on pull request #2381: doc(kamelets): debugging simple notice
Posted by GitBox <gi...@apache.org>.
heiko-braun commented on pull request #2381:
URL: https://github.com/apache/camel-k/pull/2381#issuecomment-861304167
@squakez looks like a rebase is needed
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] astefanutti commented on a change in pull request #2381: doc(kamelets): debugging simple notice
Posted by GitBox <gi...@apache.org>.
astefanutti commented on a change in pull request #2381:
URL: https://github.com/apache/camel-k/pull/2381#discussion_r655147529
##########
File path: docs/modules/ROOT/pages/troubleshooting/debugging.adoc
##########
@@ -52,3 +53,12 @@ image::debugging/remote-debugger.png[Configuration of the remote debugger in Int
Once you configure a debugger, you can **add breakpoints** to various part of the code, then connect the debugger to trigger the JVM startup.
When the debugging session is done, hitting kbd:[Ctrl+c] on the terminal where the kamel CLI is running will restore the integration to its original status.
+
+[[debugging-kamelets]]
+== Debugging Kamelets
+
+As we've seen in the previous section, all `Integration` created in Camel K are finally bundled as a Java application, hence, the possibility to debug via JVM debugger. Any `Kamelet` you will be using directly in your `Route` definition or in a `KameletBinding` is automatically converted in a `yaml` route and injected in the Camel Context to be executed. That means that you cannot directly debug a `Kamelet` as you would do with a Java or any other JVM language `Route`.
+
+However, you can troubleshoot individually each `Kamelet` definition by focusing on the specification xref:kamelets/kamelets-user.adoc#_flow[`Flow`]. As an example, you can create a simple https://camel.apache.org/camel-k/latest/languages/yaml.html[`yaml`] test `Route` substituting the `kamelet:source` or `kamelet:sink` with any mock endpoint that can help you debugging the single `Kamelet` flow. Even using a `timer` and a `log` component may be enough for a basic check.
+
+NOTE: the same idea applies for a `KameletBinding` which is converted into an `Integration` type under the hood. If you need to debug a `KameletBinding` just apply the same troubleshooting tecnique you would apply on a Camel K `Integration`.
Review comment:
nit: you would apply on a Camel K `Integration` -> you would apply on an `Integration`, I think Camel K is implicit throughout the documentation.
##########
File path: docs/modules/ROOT/pages/troubleshooting/debugging.adoc
##########
@@ -52,3 +53,12 @@ image::debugging/remote-debugger.png[Configuration of the remote debugger in Int
Once you configure a debugger, you can **add breakpoints** to various part of the code, then connect the debugger to trigger the JVM startup.
When the debugging session is done, hitting kbd:[Ctrl+c] on the terminal where the kamel CLI is running will restore the integration to its original status.
+
+[[debugging-kamelets]]
+== Debugging Kamelets
+
+As we've seen in the previous section, all `Integration` created in Camel K are finally bundled as a Java application, hence, the possibility to debug via JVM debugger. Any `Kamelet` you will be using directly in your `Route` definition or in a `KameletBinding` is automatically converted in a `yaml` route and injected in the Camel Context to be executed. That means that you cannot directly debug a `Kamelet` as you would do with a Java or any other JVM language `Route`.
+
+However, you can troubleshoot individually each `Kamelet` definition by focusing on the specification xref:kamelets/kamelets-user.adoc#_flow[`Flow`]. As an example, you can create a simple https://camel.apache.org/camel-k/latest/languages/yaml.html[`yaml`] test `Route` substituting the `kamelet:source` or `kamelet:sink` with any mock endpoint that can help you debugging the single `Kamelet` flow. Even using a `timer` and a `log` component may be enough for a basic check.
+
+NOTE: the same idea applies for a `KameletBinding` which is converted into an `Integration` type under the hood. If you need to debug a `KameletBinding` just apply the same troubleshooting tecnique you would apply on a Camel K `Integration`.
Review comment:
"which translates into an `Integration` resource under the hood" may be more representative, as conversion carries the idea that `KameletBinding` are replaced with `Integration` resources.
##########
File path: docs/modules/ROOT/pages/troubleshooting/debugging.adoc
##########
@@ -52,3 +53,12 @@ image::debugging/remote-debugger.png[Configuration of the remote debugger in Int
Once you configure a debugger, you can **add breakpoints** to various part of the code, then connect the debugger to trigger the JVM startup.
When the debugging session is done, hitting kbd:[Ctrl+c] on the terminal where the kamel CLI is running will restore the integration to its original status.
+
+[[debugging-kamelets]]
+== Debugging Kamelets
+
+As we've seen in the previous section, all `Integration` created in Camel K are finally bundled as a Java application, hence, the possibility to debug via JVM debugger. Any `Kamelet` you will be using directly in your `Route` definition or in a `KameletBinding` is automatically converted in a `yaml` route and injected in the Camel Context to be executed. That means that you cannot directly debug a `Kamelet` as you would do with a Java or any other JVM language `Route`.
+
+However, you can troubleshoot individually each `Kamelet` definition by focusing on the specification xref:kamelets/kamelets-user.adoc#_flow[`Flow`]. As an example, you can create a simple https://camel.apache.org/camel-k/latest/languages/yaml.html[`yaml`] test `Route` substituting the `kamelet:source` or `kamelet:sink` with any mock endpoint that can help you debugging the single `Kamelet` flow. Even using a `timer` and a `log` component may be enough for a basic check.
+
+NOTE: the same idea applies for a `KameletBinding` which is converted into an `Integration` type under the hood. If you need to debug a `KameletBinding` just apply the same troubleshooting tecnique you would apply on a Camel K `Integration`.
Review comment:
`tecnique` -> `technique`
##########
File path: docs/modules/ROOT/pages/troubleshooting/debugging.adoc
##########
@@ -52,3 +53,12 @@ image::debugging/remote-debugger.png[Configuration of the remote debugger in Int
Once you configure a debugger, you can **add breakpoints** to various part of the code, then connect the debugger to trigger the JVM startup.
When the debugging session is finished, hitting *ctrl+c* on the terminal where the kamel CLI is running will restore the integration to its original status.
+
+[[debugging-kamelets]]
+== Debugging Kamelets
+
+As we've seen in the previous section, all `Integration` created in Camel K are finally bundled as a Java application, hence, the possibility to debug via JVM debugger. Any `Kamelet` you will be using directly in your `Route` definition or in a `KameletBinding` is automatically converted in a `yaml` route and injected in the Camel Context to be executed. That means that you cannot directly debug a `Kamelet` as you would do with a Java or any other JVM language `Route`.
+
+However, you can troubleshoot individually each `Kamelet` definition by focusing on the specification xref:kamelets/kamelets-user.adoc#_flow[`Flow`]. As an example, you can create a simple https://camel.apache.org/camel-k/latest/languages/yaml.html[`yaml`] test `Route` substituting the `kamelet:source` or `kamelet:sink` with any mock endpoint that can help you debugging the single `Kamelet` flow. Even using a `timer` and a `log` component may be enough for a basic check.
Review comment:
@zregvart @oscerd would you know if there is a way to use `link:` of `xref:` pointing to pages from external modules (https://github.com/apache/camel-k/blob/main/docs/antora.yml#L6), or raw links can be safely used in that case?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] squakez commented on a change in pull request #2381: doc(kamelets): debugging simple notice
Posted by GitBox <gi...@apache.org>.
squakez commented on a change in pull request #2381:
URL: https://github.com/apache/camel-k/pull/2381#discussion_r650743020
##########
File path: docs/modules/ROOT/pages/troubleshooting/debugging.adoc
##########
@@ -52,3 +53,12 @@ image::debugging/remote-debugger.png[Configuration of the remote debugger in Int
Once you configure a debugger, you can **add breakpoints** to various part of the code, then connect the debugger to trigger the JVM startup.
When the debugging session is finished, hitting *ctrl+c* on the terminal where the kamel CLI is running will restore the integration to its original status.
+
+[[debugging-kamelets]]
+== Debugging Kamelets
+
+As we've seen in the previous section, all `Integration` created in Camel K are finally bundled as a Java application, hence, the possibility to debug via JVM debugger. Any `Kamelet` you will be using directly in your `Route` definition or in a `KameletBinding` is automatically converted in a `yaml` route and injected in the Camel Context to be executed. That means that you cannot directly debug a `Kamelet` as you would do with a Java or any other JVM language `Route`.
+
+However, you can troubleshoot individually each `Kamelet` definition by focusing on the specification xref:kamelets/kamelets-user.adoc#_flow[`Flow`]. As an example, you can create a simple https://camel.apache.org/camel-k/latest/languages/yaml.html[`yaml`] test `Route` substituting the `kamelet:source` or `kamelet:sink` with any mock endpoint that can help you debugging the single `Kamelet` flow. Even using a `timer` and a `log` component may be enough for a basic check.
Review comment:
I thought the same. However these languages seem to be added later in the process by the merge with main Camel, so, I am not sure if I can still reference via `link:` or `xref:`
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] zregvart commented on a change in pull request #2381: doc(kamelets): debugging simple notice
Posted by GitBox <gi...@apache.org>.
zregvart commented on a change in pull request #2381:
URL: https://github.com/apache/camel-k/pull/2381#discussion_r655977436
##########
File path: docs/modules/ROOT/pages/troubleshooting/debugging.adoc
##########
@@ -52,3 +53,12 @@ image::debugging/remote-debugger.png[Configuration of the remote debugger in Int
Once you configure a debugger, you can **add breakpoints** to various part of the code, then connect the debugger to trigger the JVM startup.
When the debugging session is finished, hitting *ctrl+c* on the terminal where the kamel CLI is running will restore the integration to its original status.
+
+[[debugging-kamelets]]
+== Debugging Kamelets
+
+As we've seen in the previous section, all `Integration` created in Camel K are finally bundled as a Java application, hence, the possibility to debug via JVM debugger. Any `Kamelet` you will be using directly in your `Route` definition or in a `KameletBinding` is automatically converted in a `yaml` route and injected in the Camel Context to be executed. That means that you cannot directly debug a `Kamelet` as you would do with a Java or any other JVM language `Route`.
+
+However, you can troubleshoot individually each `Kamelet` definition by focusing on the specification xref:kamelets/kamelets-user.adoc#_flow[`Flow`]. As an example, you can create a simple https://camel.apache.org/camel-k/latest/languages/yaml.html[`yaml`] test `Route` substituting the `kamelet:source` or `kamelet:sink` with any mock endpoint that can help you debugging the single `Kamelet` flow. Even using a `timer` and a `log` component may be enough for a basic check.
Review comment:
`xref` needs to be used here here, absolute links are not allowed to camel.apache.org domain. See the [xref reference](https://docs.antora.org/antora/2.3/page/version-and-component-xrefs/).
```suggestion
However, you can troubleshoot individually each `Kamelet` definition by focusing on the specification xref:kamelets/kamelets-user.adoc#_flow[`Flow`]. As an example, you can create a simple xref:camel-k:languages:yaml.adoc[`yaml`] test `Route` substituting the `kamelet:source` or `kamelet:sink` with any mock endpoint that can help you debugging the single `Kamelet` flow. Even using a `timer` and a `log` component may be enough for a basic check.
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] astefanutti commented on a change in pull request #2381: doc(kamelets): debugging simple notice
Posted by GitBox <gi...@apache.org>.
astefanutti commented on a change in pull request #2381:
URL: https://github.com/apache/camel-k/pull/2381#discussion_r655147529
##########
File path: docs/modules/ROOT/pages/troubleshooting/debugging.adoc
##########
@@ -52,3 +53,12 @@ image::debugging/remote-debugger.png[Configuration of the remote debugger in Int
Once you configure a debugger, you can **add breakpoints** to various part of the code, then connect the debugger to trigger the JVM startup.
When the debugging session is done, hitting kbd:[Ctrl+c] on the terminal where the kamel CLI is running will restore the integration to its original status.
+
+[[debugging-kamelets]]
+== Debugging Kamelets
+
+As we've seen in the previous section, all `Integration` created in Camel K are finally bundled as a Java application, hence, the possibility to debug via JVM debugger. Any `Kamelet` you will be using directly in your `Route` definition or in a `KameletBinding` is automatically converted in a `yaml` route and injected in the Camel Context to be executed. That means that you cannot directly debug a `Kamelet` as you would do with a Java or any other JVM language `Route`.
+
+However, you can troubleshoot individually each `Kamelet` definition by focusing on the specification xref:kamelets/kamelets-user.adoc#_flow[`Flow`]. As an example, you can create a simple https://camel.apache.org/camel-k/latest/languages/yaml.html[`yaml`] test `Route` substituting the `kamelet:source` or `kamelet:sink` with any mock endpoint that can help you debugging the single `Kamelet` flow. Even using a `timer` and a `log` component may be enough for a basic check.
+
+NOTE: the same idea applies for a `KameletBinding` which is converted into an `Integration` type under the hood. If you need to debug a `KameletBinding` just apply the same troubleshooting tecnique you would apply on a Camel K `Integration`.
Review comment:
nit: you would apply on a Camel K `Integration` -> you would apply on an `Integration`, I think Camel K is implicit throughout the documentation.
##########
File path: docs/modules/ROOT/pages/troubleshooting/debugging.adoc
##########
@@ -52,3 +53,12 @@ image::debugging/remote-debugger.png[Configuration of the remote debugger in Int
Once you configure a debugger, you can **add breakpoints** to various part of the code, then connect the debugger to trigger the JVM startup.
When the debugging session is done, hitting kbd:[Ctrl+c] on the terminal where the kamel CLI is running will restore the integration to its original status.
+
+[[debugging-kamelets]]
+== Debugging Kamelets
+
+As we've seen in the previous section, all `Integration` created in Camel K are finally bundled as a Java application, hence, the possibility to debug via JVM debugger. Any `Kamelet` you will be using directly in your `Route` definition or in a `KameletBinding` is automatically converted in a `yaml` route and injected in the Camel Context to be executed. That means that you cannot directly debug a `Kamelet` as you would do with a Java or any other JVM language `Route`.
+
+However, you can troubleshoot individually each `Kamelet` definition by focusing on the specification xref:kamelets/kamelets-user.adoc#_flow[`Flow`]. As an example, you can create a simple https://camel.apache.org/camel-k/latest/languages/yaml.html[`yaml`] test `Route` substituting the `kamelet:source` or `kamelet:sink` with any mock endpoint that can help you debugging the single `Kamelet` flow. Even using a `timer` and a `log` component may be enough for a basic check.
+
+NOTE: the same idea applies for a `KameletBinding` which is converted into an `Integration` type under the hood. If you need to debug a `KameletBinding` just apply the same troubleshooting tecnique you would apply on a Camel K `Integration`.
Review comment:
"which translates into an `Integration` resource under the hood" may be more representative, as conversion carries the idea that `KameletBinding` are replaced with `Integration` resources.
##########
File path: docs/modules/ROOT/pages/troubleshooting/debugging.adoc
##########
@@ -52,3 +53,12 @@ image::debugging/remote-debugger.png[Configuration of the remote debugger in Int
Once you configure a debugger, you can **add breakpoints** to various part of the code, then connect the debugger to trigger the JVM startup.
When the debugging session is done, hitting kbd:[Ctrl+c] on the terminal where the kamel CLI is running will restore the integration to its original status.
+
+[[debugging-kamelets]]
+== Debugging Kamelets
+
+As we've seen in the previous section, all `Integration` created in Camel K are finally bundled as a Java application, hence, the possibility to debug via JVM debugger. Any `Kamelet` you will be using directly in your `Route` definition or in a `KameletBinding` is automatically converted in a `yaml` route and injected in the Camel Context to be executed. That means that you cannot directly debug a `Kamelet` as you would do with a Java or any other JVM language `Route`.
+
+However, you can troubleshoot individually each `Kamelet` definition by focusing on the specification xref:kamelets/kamelets-user.adoc#_flow[`Flow`]. As an example, you can create a simple https://camel.apache.org/camel-k/latest/languages/yaml.html[`yaml`] test `Route` substituting the `kamelet:source` or `kamelet:sink` with any mock endpoint that can help you debugging the single `Kamelet` flow. Even using a `timer` and a `log` component may be enough for a basic check.
+
+NOTE: the same idea applies for a `KameletBinding` which is converted into an `Integration` type under the hood. If you need to debug a `KameletBinding` just apply the same troubleshooting tecnique you would apply on a Camel K `Integration`.
Review comment:
`tecnique` -> `technique`
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] astefanutti commented on a change in pull request #2381: doc(kamelets): debugging simple notice
Posted by GitBox <gi...@apache.org>.
astefanutti commented on a change in pull request #2381:
URL: https://github.com/apache/camel-k/pull/2381#discussion_r656016479
##########
File path: docs/modules/ROOT/pages/troubleshooting/debugging.adoc
##########
@@ -52,3 +53,12 @@ image::debugging/remote-debugger.png[Configuration of the remote debugger in Int
Once you configure a debugger, you can **add breakpoints** to various part of the code, then connect the debugger to trigger the JVM startup.
When the debugging session is finished, hitting *ctrl+c* on the terminal where the kamel CLI is running will restore the integration to its original status.
+
+[[debugging-kamelets]]
+== Debugging Kamelets
+
+As we've seen in the previous section, all `Integration` created in Camel K are finally bundled as a Java application, hence, the possibility to debug via JVM debugger. Any `Kamelet` you will be using directly in your `Route` definition or in a `KameletBinding` is automatically converted in a `yaml` route and injected in the Camel Context to be executed. That means that you cannot directly debug a `Kamelet` as you would do with a Java or any other JVM language `Route`.
+
+However, you can troubleshoot individually each `Kamelet` definition by focusing on the specification xref:kamelets/kamelets-user.adoc#_flow[`Flow`]. As an example, you can create a simple https://camel.apache.org/camel-k/latest/languages/yaml.html[`yaml`] test `Route` substituting the `kamelet:source` or `kamelet:sink` with any mock endpoint that can help you debugging the single `Kamelet` flow. Even using a `timer` and a `log` component may be enough for a basic check.
Review comment:
Thanks @zregvart!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] apupier commented on a change in pull request #2381: doc(kamelets): debugging simple notice
Posted by GitBox <gi...@apache.org>.
apupier commented on a change in pull request #2381:
URL: https://github.com/apache/camel-k/pull/2381#discussion_r650711462
##########
File path: docs/modules/ROOT/pages/troubleshooting/debugging.adoc
##########
@@ -52,3 +53,12 @@ image::debugging/remote-debugger.png[Configuration of the remote debugger in Int
Once you configure a debugger, you can **add breakpoints** to various part of the code, then connect the debugger to trigger the JVM startup.
When the debugging session is finished, hitting *ctrl+c* on the terminal where the kamel CLI is running will restore the integration to its original status.
+
+[[debugging-kamelets]]
+== Debugging Kamelets
+
+As we've seen in the previous section, all `Integration` created in Camel K are finally bundled as a Java application, hence, the possibility to debug via JVM debugger. Any `Kamelet` you will be using directly in your `Route` definition or in a `KameletBinding` is automatically converted in a `yaml` route and injected in the Camel Context to be executed. That means that you cannot directly debug a `Kamelet` as you would do with a Java or any other JVM language `Route`.
+
+However, you can troubleshoot individually each `Kamelet` definition by focusing on the specification xref:kamelets/kamelets-user.adoc#_flow[`Flow`]. As an example, you can create a simple https://camel.apache.org/camel-k/latest/languages/yaml.html[`yaml`] test `Route` substituting the `kamelet:source` or `kamelet:sink` with any mock endpoint that can help you debugging the single `Kamelet` flow. Even using a `timer` and a `log` component may be enough for a basic check.
+
+NOTE: the same idea applies for a `KameletBinding` which is converted into an `Integration` type under the hood. If you need to debug a `KameletBinding` just apply the same troubleshooting tecnique you would apply on a Camel K `Integration`.
Review comment:
```suggestion
NOTE: the same idea applies for a `KameletBinding` which is converted into an `Integration` type under the hood. If you need to debug a `KameletBinding` just apply the same troubleshooting technique you would apply on a Camel K `Integration`.
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org