WildFly环境下REST接口返回404但JSP可访问，求排查方案

Let’s walk through the most likely causes for your 404 error—since your JSPs load fine, your app is definitely deployed correctly, so the issue is tied to your REST endpoint configuration. Here’s what to check step by step:

1. Validate Your REST Application Path Mapping #

First, confirm how your JAX-RS application is mapped to a base path:

• If you’re using a custom Application subclass, make sure it has the @ApplicationPath("/ws") annotation. This tells RestEasy to route all requests starting with /ws to your REST resources:

  @ApplicationPath("/ws")
  public class MyRestApplication extends Application {
      // Add resource classes explicitly or let RestEasy scan them automatically
  }
  

• If you’re configuring via web.xml, check that the RestEasy servlet is mapped to /ws/* (the wildcard * is critical to match subpaths like /ws/aluno):

  <servlet-mapping>
      <servlet-name>Resteasy</servlet-name>
      <url-pattern>/ws/*</url-pattern>
  </servlet-mapping>
  

2. Check Your REST Resource Annotations #

Double-check your resource class and method annotations—small mistakes here are the most common cause of 404s:

• Ensure your resource class has a @Path("/aluno") annotation (matches the end of your test URL).
• Make sure your endpoint method has an HTTP verb annotation like @GET—RestEasy won’t expose methods without this:

  @Path("/aluno")
  public class AlunoResource {
      @GET
      @Produces(MediaType.APPLICATION_JSON)
      public List<Aluno> getAllAlunos() {
          // Your implementation logic here
      }
  }
  

• Confirm RestEasy is scanning for your resource class. If you’re using an Application subclass, either list the resource explicitly in getClasses() or set resteasy.scan to true in web.xml:

  <context-param>
      <param-name>resteasy.scan</param-name>
      <param-value>true</param-value>
  </context-param>
  

3. Fix WildFly-RestEasy Version Conflicts #

WildFly includes its own built-in RestEasy instance—if your pom.xml packages a different RestEasy version into your WAR, it can cause deployment issues or broken mappings:

• Set all RestEasy dependencies to provided scope so your app uses WildFly’s built-in version instead (match the version to your WildFly release, e.g., WildFly 27 uses RestEasy 6.2.x):

  <dependency>
      <groupId>org.jboss.resteasy</groupId>
      <artifactId>resteasy-jaxrs</artifactId>
      <version>your-version</version>
      <scope>provided</scope>
  </dependency>
  <dependency>
      <groupId>org.jboss.resteasy</groupId>
      <artifactId>resteasy-jackson2-provider</artifactId>
      <version>your-version</version>
      <scope>provided</scope>
  </dependency>
  

4. Confirm Your Context Root #

Make sure your app’s context root is indeed teachmanager:

• Check your WAR filename—WildFly uses the WAR name as the default context root (so teachmanager.war maps to /teachmanager).
• If you’ve customized the context root via jboss-web.xml, verify it’s set correctly:

  <jboss-web>
      <context-root>teachmanager</context-root>
  </jboss-web>
  

  You can also confirm this in the WildFly management console (http://localhost:9990) under the Deployments section.

5. Enable Debug Logging to Diagnose Scanning Issues #

If you’re still stuck, enable RestEasy debug logging to see if your resource class is being detected:

• Edit WildFly’s standalone.xml (or domain.xml) to add a logger for RestEasy:

  <subsystem xmlns="urn:jboss:domain:logging:8.0">
      <!-- ... existing loggers ... -->
      <logger category="org.jboss.resteasy">
          <level name="DEBUG"/>
      </logger>
  </subsystem>
  

• Start WildFly and check the server logs for lines like Scanning for JAX-RS resources or Adding resource class com.yourpackage.AlunoResource. If you don’t see your resource listed, RestEasy isn’t finding it—double-check your package scanning settings.

Start with the first two checks (path mapping and annotations)—these are the most frequent culprits when JSPs work but REST endpoints don’t.

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