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: [email protected]
