Maven4构建下WebSocket握手404错误求助（Angular+Electron+Spring+Tomcat7）

Since you’ve already confirmed plain Tomcat + JSR-356 WebSocket works fine, and ruled out the javax.websocket-api dependency scope issue, the problem is almost certainly tied to how Maven is building or packaging your application. Here are targeted troubleshooting steps to fix that 404 handshake error:

• Verify your WAR package structure
  Maven can sometimes mishandle class inclusion or dependency packaging. First, unpack your built WAR (from the target directory) and check:

  • Does WEB-INF/classes contain your WebSocket endpoint class (e.g., the one annotated with @ServerEndpoint("/gs-guide-websocket"))? If not, your Maven build isn’t compiling or including the class—double-check your <build> configuration in pom.xml to ensure <sourceDirectory> and <resources> point to the correct paths.
  • Run mvn dependency:tree to confirm no transitive dependencies are pulling in javax.websocket-api into WEB-INF/lib. Even with provided scope, some dependencies might sneak it in—use <exclusions> in your pom to block that if needed.

• Validate endpoint path and application context alignment
  Your frontend is targeting ws://127.0.0.1:9090/tests/gs-guide-websocket, which means:

  • Your app’s context path is /tests—make sure this matches how you’re deploying to Tomcat. If you’re using tomcat7-maven-plugin, check that <path> is set to /tests in the plugin config. If deploying manually, confirm the WAR filename is tests.war or the <Context> entry in Tomcat’s server.xml sets the path correctly.
  • The endpoint’s @ServerEndpoint annotation should be exactly /gs-guide-websocket (not prefixed with /tests—the context path is handled by Tomcat). A typo here will cause a silent 404.

• Check JDK compatibility in Maven build
  Tomcat 7.0.93 supports JDK 6+, but if your Maven build is compiling with a higher JDK version without setting the correct source/target levels, it can cause class loading issues that manifest as 404. Add or verify these properties in your pom.xml:

  <properties>
      <maven.compiler.source>1.7</maven.compiler.source>
      <maven.compiler.target>1.7</maven.compiler.target>
  </properties>
  

  Adjust to 1.6 if you’re using an older JDK, but 1.7 is safe for Tomcat 7.

• Audit Maven plugins for unintended modifications
  Plugins like maven-war-plugin or maven-shade-plugin can alter your WAR in unexpected ways:

  • For maven-war-plugin, check if <packagingExcludes> or <webResources> are excluding your WebSocket endpoint classes from the final WAR. Ensure no rules are targeting the package where your endpoint lives.
  • If you’re using maven-shade-plugin, it might be merging classes or changing classloader order, which can break Tomcat’s ability to detect WebSocket endpoints. Try removing it temporarily to see if the issue goes away.

• Enable Tomcat WebSocket debug logs
  To get concrete details about why Tomcat isn’t picking up your endpoint, enable debug logging for the WebSocket module:

  1. Open TOMCAT_HOME/conf/logging.properties
  2. Add these lines:

     org.apache.tomcat.websocket.level = FINE
     org.apache.tomcat.websocket.handlers.level = FINE
     

  3. Restart Tomcat and watch the localhost.log for entries about endpoint scanning or loading. You’ll likely see errors about missing classes, annotation processing failures, or path mismatches that point directly to the problem.

Since you’ve proven the core WebSocket setup works without Maven, focusing on how Maven modifies your build output and dependencies should lead you to the fix.

内容的提问来源于stack exchange，提问作者EnzoMolion