Repository navigation
No Documentation of how to Debug Javascript in a Spring Boot Application #1379
Description
We develop a Spring Boot App. Most of the front end we develop with Thymeleaf. We use Windows 10/11. Now, we have a more significant growing part that we develop with JavaScript.
I tested it with the WWD snapshot from Friday (27.09), I believe, and the Version from the Eclipse marketplace.
To debug the Javascript part, I set up different configurations.
When I start the debug session, the Javascript Source Code is not found, and the program does not stop on the breakpoints. Does that work at all?
When I start to debug from the HTML File and not from the URL, it works.
A similar test works with VS-Code when I use URL-Base Adress, but I prefer one IDE.
Activity
3ueb commentedon Oct 29, 2023
Here is the setup in VSCode, I open the static Folter.
I was hopping that the new Webroot option from WWD solve the problem.
mickaelistria commentedon Oct 30, 2023
It could be that the webroot is not properly set by Wild Web Developer to latest debug adapter.
Please check https://github.com/microsoft/vscode-js-debug/blob/main/OPTIONS.md and the code of ChromeAttachDebugDelegate in this repo, it looks like the
webrootis never set here (and that of course can cause issue).3ueb commentedon Nov 4, 2023
So far, what I found out is that these options are useless for Chrome Debug and the options only for Firefox. Someone may know more about the options.
The "Chrome Debug" Configuration is not using ChromeAttachDebugDelegate; it only uses classes in the package org.eclipse.wildwebdeveloper.debug.node
ChromeAttachDebugDelegate is part of the package org.eclipse.wildwebdeveloper.debug.chrome.
3ueb commentedon Nov 4, 2023
What does that mean "Active Member Companies: " RedHat? Is there a programmer from RedHat, who fix this?
Or do I have to do it if I want to use it in any way?
akurtakov commentedon Nov 5, 2023
It means there are active committers affiliated with Red Hat. It doesn't put any implications that any of the committers will work on a fix for a given issue.
This is always the best action. Most of the time committers want to fix everything but being spread between dozen(s) of projects (some of which like Platform, LSP4E, TM4E, M2E being building blocks for this one) means there are always more important issues than this one and we quite likely will not get to such an issue any time soon (if at all).
mickaelistria commentedon Nov 6, 2023
@3ueb if you can manage to submit a PR that fixes this issue, it would be more than welcome and most effective as we always try to prioritize community reviews; while we cannot currently prioritize own development of a fix here at the moment.