Camel K is providing a new feature to Java debug deployed integrations. Before VS Code Tooling for Apache Camel K 0.0.25, more complex steps were required to leverage the VS Code Java debugging capabilities as explained in this previous blogpost.
I recorded a video which is following the steps in this blogpost.
To have a breakpoint during the execution of the Camel Route, as opposite at the creation of the Camel Route, you need to add a small piece of code. This is a classical trick for Java debugging of Camel Routes, not specific to Camel K.
The trick consists of adding a Processor between the steps you want to observe. It will be something like:
.process(new Processor(){ @Override public void process(Exchange exchange) throws Exception { System.out.println("can be breakpoint on this line"); } })
Then, you can add a breakpoint to the line by clicking in the left ruler. A red dot will appear.
You can then start the integration:
Note: If starting in --dev, it will allow to automatically reload the Integration. But take care, debugger will need to be restarted on each change. Meaning that the next two steps will need to be repeated.
In Integrations view, wait that the integration is running, then right-click on the integration and select Start Java debugger on Camel K Integration.
Now, it is time to enjoy. You can notice that you have access to the message content. It is providing a good insight into what is going on in the Camel Route.
There is room for improvements, provide your feedback and ideas!
You can start discussions on Zulip camel-tooling channel.
You can create and vote for issues on GitHub VS Code Tooling support for Apache Camel K repository.
You can create and vote for issues on the related epic in Jira which is used by the Red Hat Integration tooling team.