would surely leads to a Debug Adapter Protocol implementation.

Eclipse Desktop and VS Code are supporting the protocol already but Che seems not supporting it completely, see https://github.com/eclipse/che/issues/8383

technical information:

• Camel is using JMX
• Fuse Tooling has implemented the usage of a debugger via JMX using the Eclipse debug system. It is relying on JBoss Tools JMX plugins for the JMX communication. it is supported using local/remote JMX and via "classic JMX" and through http using Jolokia. (if we can extract all this Jboss tools code, it can surely be the same for DAP). Please note that Fuse Tooling has implemented it for xml dsl only and it requires design definition to include ids.
• entry point org.eclipse.lsp4j.debug.launch.DSPLauncher
• 2 modes: attach/launch. The easier in our case is to use the attach mode. The launch means that we need to also launch the application (but we don't have the whole project for now easily)
• client needs to generate a messages.json with connection information. in our case, it will surely be the JMX URL
• the Camel Debugger will be responsible to convert a breakpoint line to the Camel JMX instruction using ids (and vice-versa)
• reusing JBoss Tools JMX will be complicated (would require to embed a big OSGi instance) so manipulating the JMX API directly seems the way to go as first iteration. it means that it won't work through http with Jolokia (but it can surely be reimplemented in an effort of extracting JBoss Tools JMX support)