在Wildfly 9.0部署JAXRS编写的Java WAR（REST API）时遇问题

Hey there! Let's figure out why your REST API runs smoothly on Tomcat but hits errors when deployed to WildFly 9.0. These two application servers have key architectural differences that often trigger this kind of mismatch—here are the most common fixes to try:

1. Fix Dependency Conflicts (Most Likely Culprit) #

WildFly comes bundled with full Java EE stack implementations (like RESTEasy for JAX-RS, Hibernate for JPA, and more), while Tomcat is a lightweight servlet container that requires you to package many of these dependencies yourself. If your WAR includes libraries that WildFly already provides, you’ll hit classloading conflicts.

• Check your build config: For Maven projects, mark Java EE API dependencies (e.g., javax.ws.rs-api, hibernate-core, javax.servlet-api) as <scope>provided</scope>. For Gradle, use compileOnly instead. This tells your build tool not to include these JARs in the WAR, letting WildFly use its own versions.
• Example Maven snippet:

  <dependency>
      <groupId>javax.ws.rs</groupId>
      <artifactId>javax.ws.rs-api</artifactId>
      <version>2.0</version>
      <scope>provided</scope>
  </dependency>
  

2. Verify JNDI Resource Configuration #

If your REST API uses database connections or other external resources, Tomcat and WildFly handle JNDI differently:

• Tomcat uses context.xml to define datasources, but WildFly requires you to configure datasources in its standalone.xml or domain.xml file.
• Ensure your project references the correct WildFly-style JNDI name (e.g., java:jboss/datasources/YourDBName) instead of Tomcat’s format (like jdbc/YourDBName). You can map this in web.xml or a WildFly-specific jboss-web.xml descriptor.

3. Align Servlet API Version #

WildFly 9 supports Servlet 3.1, so if your project is built for an older Servlet version (e.g., 2.5), compatibility issues can arise:

• Open your web.xml and confirm the root element uses the correct namespace and version:

  <web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
           version="3.1">
  

4. Use WildFly-Specific Deployment Descriptors #

WildFly uses custom descriptors to control classloading and deployment behavior. If you need to override default module loading, create a jboss-deployment-structure.xml in your WAR’s WEB-INF directory:

• For example, to exclude a conflicting WildFly module:

  <jboss-deployment-structure>
      <deployment>
          <exclusions>
              <module name="org.hibernate"/>
          </exclusions>
      </deployment>
  </jboss-deployment-structure>
  

5. Dig Into Error Details #

If you can share the specific error stack trace (from the screenshot you mentioned), we can narrow this down even further. Common red flags include:

• ClassNotFoundException: A required class isn’t being loaded—either it’s missing from the WAR or conflicting with WildFly’s version.
• NoSuchMethodError: A class method exists in one version of a library but not the one WildFly is using.

Start with dependency checks first—this is the most frequent cause of Tomcat-to-WildFly deployment failures. Let me know if you hit a specific error we can troubleshoot further!

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