JavaScript Debugger stopped working when migrating to Tomcat 10

Answered

Existing project using tomcat 8.5.11/Java 11. Migrated project to 10.1.18/ Java temurin 17. Debugging an angular 16 application.

Intellij JavaScript debugger stopped working after the migration. 

Rebuild project from scratch - no change. Attempted to migrate existing 8.5.11 project to 10.1.18/17 - no change.

Existing project 8.5.11 - still connects to Debugger and breakpoints respond, shows “webpack” connection in scripts.

With tomcat 10 - JavaScript breakpoints are ignored and no “red check marks” appear; does not show “webpack” in scripts - but does show the compiled JS files, but no map references.

Application runs as expected with no errors after migration - but JavaScript Debugger no longer works, no reasoning or errors given (like connection errors)

Any advice or direction as to where I can look to fix this would be appreciated.

 

0
7 comments

Which Angular version do you use? What do your run configurations look like?

0

Thank you so much for for the response.

Tomcat 8.5 version is running Ang 16; and debugging is working. On Tomcat 10, I've tried both 16 (identical build scheme) and 17 - and that didn't get the debugger working. The run configs between Tomcat 8 and 10 and ‘nearly’ identical, and I take steps to make sure I'm never running them at the same time.

I've narrowed down the difference to the required changes that I had to make for HTTPS in Tomcat 10: 

<!-- Tomcat 8 -->
<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
maxThreads="200" SSLEnabled="true" enableLookups="false"
secure="true" scheme="https" disableUploadTimeout="true"
keystoreFile="conf/.keystore" keystorePass="<kspassword>"
clientAuth="false" sslProtocol="TLS"/>
 
<!-- Tomcat 10 -->
<Connector protocol="org.apache.coyote.http11.Http11NioProtocol"
          port="8443" maxThreads="200"
          scheme="https" secure="true" SSLEnabled="true">
     <SSLHostConfig>
          <Certificate certificateKeystoreFile="conf/.keystore"
          certificateKeystorePass="<kspassword>"
          type="RSA" />
     </SSLHostConfig>
</Connector>

I've tried a few different add-ons that I could find easily, but not having any luck. But, I could down the wrong path; I've made new keys and tested them in 8/10 and that does seem to change the outcome; still can't the JavaScript Debugger to work with 10, but still have it working with 8.

Other places to check? Ideas? further suggestions?

Again, I appreciate your time.

0

The issue can indeed be related to certificates. Please could you share the idea.log (Help > Show Log in …) after reproducing the issue? 

0

Thank you again for your support.

I've uploaded the two log files in this zip:

Upload id: 2024_04_29_23Cf3k9bfsiUUASU4f94i8 (file: log_wdr_tomcat_issue.zip)

The t8 example does hit a breakpoint in the angular app.component.

The t10 -blows right through the same breakpoint.

0
Thank you!

I can see some errors related to sourcemaps decoding - looks like some sourcemaps can't be parsed. But these exceptions are not necessary the issue.
Could you try composing a sample project that reproduces the issue?
0

Elena, thanks again for your follow up.

This did send me down the right track! The project itself is a large 18yo pre-spring-boot java application; so refocused from the ground up to build a sample project that would replicate the problem. After finding there were no problems on my system with standard java17/tomcat 10/angular intellij debugging; I set upon recreating the base spring structure/security that our application is using.

Only to find that when doing a full review of the applicationContext-security settings (which had to be changed by a colleague for the tomcat 8→ 10 migration) I found that an errant commit had knocked out the access mapping for the js.map files; which completely shut down JS Debugging.

TL/DR: For future searchers; if having problems with spring/tomcat JS debugging confirm you are allowing the “*.js.map” files to get through security (intercept-urls), as these are generally insecure and for debugging purposes only, so may need to be environmentally safe or switchable/configurable.

Appreciate the support and your time in helping - all back up and debugging now!

1

I'm pleased to hear that it is now functioning well for you! Thank you for the tips, we appreciate you sharing this information with us.

1

Please sign in to leave a comment.