Repository navigation
JSP breakpoints are often unverified, but breakpoints in generated index_jsp.java map and stop in index.jsp #1613
Description
Summary
In VS Code (Java debugger attach mode), breakpoints set directly in JSP are frequently shown as Unverified breakpoint.
However, if I set a breakpoint in the generated servlet source (index_jsp.java) on an executable line, the debugger can stop and map back to the corresponding line in index.jsp.
This looks like a JSP/SMAP line mapping + breakpoint verification inconsistency.
Environment
- VS Code:
- Version: 1.109.5 (user setup)
- Commit: 072586267e68ece9a47aa43f8c108e0dcbf44622
- Date: 2026-02-19T19:43:32.382Z
- Electron: 39.3.0
- Chromium: 142.0.7444.265
- Node.js: 22.21.1
- OS: Windows_NT x64 10.0.26200
- WSL:
- Ubuntu 20.04 LTS (Focal Fossa)
- Extensions:
- Debugger for Java (
vscjava.vscode-java-debug) v0.58.5 - Extension Pack for Java (
vscjava.vscode-java-pack) v0.30.5 - Language Support for Java by Red Hat (
redhat.java) v1.52.0
- Debugger for Java (
- Java/Build tools:
- java (sdk env output):
11.0.28-tem java --versionoutput at runtime:OpenJDK 21.0.8 Temurin- ant:
1.10.14 - maven:
3.9.12
- java (sdk env output):
- Tomcat:
- Apache Tomcat 9.0.115
Debug configuration (launch.json)
{
"version": "0.2.0",
"configurations": [
{
"name": "Attach to Tomcat9 (Manual Start)",
"type": "java",
"request": "attach",
"hostName": "localhost",
"port": 8000
},
{
"name": "Redeploy + Start + Attach (Tomcat9)",
"type": "java",
"request": "attach",
"hostName": "localhost",
"port": 8000,
"preLaunchTask": "ant: debug-redeploy-start"
}
]
}Reproduction project snippets
JSP source
WebContent/WEB-INF/contents/index.jsp
<%
...
String aaa = (String)(request.getAttribute("aaa"));
%>
...
<div>
<%=aaa%>
</div>Generated servlet source
<CATALINA_BASE>/work/Catalina/localhost/jg-web3/org/apache/jsp/WEB_002dINF/contents/index_jsp.java
...
String aaa = (String)(request.getAttribute("aaa"));
...
out.print(aaa);
...Steps to reproduce
- Start Tomcat with JPDA enabled (port 8000).
- Attach using VS Code Java debugger.
- Set breakpoint directly in
index.jspscriptlet line(s). - Access the page.
- Observe: breakpoint is often
Unverified breakpointand not hit. - Open generated
index_jsp.javaunder Tomcatworkdirectory. - Set breakpoint on an executable line in
index_jsp.java. - Access the same page again.
- Observe: debugger can stop, and VS Code maps to
index.jspline.
Actual behavior
- JSP breakpoints are frequently unverified.
- Breakpoints in
index_jsp.javaonly work on executable lines. - If the line is executable, stop can map to same line number in JSP.
- Breakpoints on blank/non-executable lines in
index_jsp.javado not stop.
Expected behavior
- Breakpoints set on executable JSP lines should be verified and consistently hit.
- JSP source breakpoint behavior should be consistent with generated servlet mapping.
Additional notes
- This behavior suggests a gap in JSP source mapping / breakpoint verification handling.
- It would be helpful if debugger diagnostics clarified why a JSP breakpoint is unverified.
Evidence
- VS Code UI shows
Unverified Breakpointon JSP lines (screenshot attached). - Generated servlet breakpoints can be hit only on executable lines.
in additional
This investigation and report were prepared in collaboration with GPT-5.3-Codex.
Activity
github-actions commentedon Feb 25, 2026
Hi jg-shinji-ueda, I'm an AI Support assistant here to help with your issue. While the team reviews your request, I wanted to provide some possible tips and documentation that might help you in the meantime.
Suggested Workarounds and References
• Workaround: Set breakpoints in the generated servlet source (
index_jsp.java) on executable lines. These breakpoints will be verified and will map back to your JSP at runtime (e.g. theout.print(…)call).• Enable debug adapter logging to diagnose why JSP breakpoints are unverified:
Then inspect the Debug Console for messages like “Failed to set breakpoint”.
• File an enhancement request against the Java debugger to improve JSP/SMAP breakpoint verification in
vscode-java-debug.High-Confidence Reference
• Unverified Breakpoint #1268
– Shows grey/unverified breakpoints when they’re placed on non-executable lines and explains that only executable lines can be hot-swapped and hit.
• URL: redhat-developer/vscode-java#1268
Other references with low confidence
• Breakpoints run to a wrong code line #998
– Reports mismatched source-to-bytecode line mapping in Spring Boot; not JSP-specific but also about mapping inconsistencies.
• URL: #998
The team will respond to your issue shortly. I hope these suggestions are helpful in the meantime. If this comment helped you, please give it a 👍. If the suggestion was not helpful or incorrect, please give it a 👎. Your feedback helps us improve!
jg-shinji-ueda commentedon Feb 26, 2026
Thanks for the suggestions. I tested this again and wanted to share concrete results.
Environment:
Observed behavior:
org.apache.jsp.WEB_002dINF.contents.index_jsp), a breakpoint in_jspService(for example line 145) is verified but never hit.index_jsp.javais hit, but that appears to be static initialization (class load), not request-time JSP execution.So in my case, the “use generated servlet breakpoints” workaround is not sufficient for request-time JSP debugging.
If useful, I can provide verbose DAP logs and a minimal repro project.
wenytang-ms commentedon Mar 2, 2026
jg-shinji-ueda Please provide a complete project and detailed reproduction steps so that we can accurately debug and confirm the issue. Thank you.
jg-shinji-ueda commentedon Mar 6, 2026
wenyt (@wenytang-ms)
Thank you for replay. 😄
Oh,
complete project..I have internal code in that project.
Please bear with me while I prepare it! I'll get a sample project ready for sharing.
If you need any information beforehand, even partial, please let me know what you require.
Best regards.
wenytang-ms commentedon Mar 6, 2026
please provide the project and repro steps. thanks!
if there any record is best!
github-actions commentedon Mar 21, 2026
This issue has been closed automatically because it needs more information and has not had recent activity. Please reach out if you have or find the answers we need so that we can investigate further.