WebSphere调用WebService遇javax.servlet.UnavailableException错误求助

Hey there, let's break down this issue—this error usually pops up when WebSphere tries to treat your JAX-WS endpoint class as a regular Servlet, but it doesn't fit the Servlet contract, or there's a misconfiguration causing the container to misinterpret it. Here are targeted steps to diagnose and fix this:

• Double-check your web.xml configuration
  The most common culprit here is accidentally registering your @WebService annotated class as a <servlet> in web.xml. JAX-WS endpoints don't need to be declared as Servlets—WebSphere's JAX-WS container should auto-detect them via the @WebService annotation. If you have a <servlet> entry pointing to this class, remove it immediately; that's why the container is trying to load it as a Servlet (which it's not, unless you explicitly extended HttpServlet, which you shouldn't need to for a standard JAX-WS endpoint).

• Verify class loader compatibility with WebSphere's JAX-WS stack
  You mentioned setting class loader to Parent Last, but your project includes several JAX-WS/JAXB jars (jaxb-api, jaxb-core, jaxb-impl) that might conflict with WebSphere's built-in implementations. WebSphere has its own JAX-WS runtime, and using external JAXB/JAX-WS jars can cause class loading mismatches. Try removing these jars from your project and let WebSphere use its native versions—this often resolves hidden class conflicts that prevent the container from recognizing your class as a valid WebService endpoint.

• Check for conflicting dependencies
  Looking at your jar list, you have both log4j-1.2.16.jar and log4j-api-2.7.jar/log4j-core-2.7.jar in the classpath. Mixing Log4j 1.x and 2.x is a guaranteed source of class loading chaos, which can indirectly break other components like JAX-WS. Pick one Log4j version and remove the other jars. Additionally, jars like xalan-2.7.2.jar and xercesImpl-2.11.0.jar are already provided by WebSphere; keeping them in your project with Parent Last might cause XML parsing conflicts that disrupt the JAX-WS endpoint initialization.

• Confirm annotation scanning is enabled
  Make sure WebSphere is set to scan for annotations in your application. In the WebSphere Admin Console, navigate to your application's configuration > Web module properties and ensure that Enable annotation scanning is checked. If this is disabled, the @WebService annotation won't be detected, and the container might fall back to incorrect servlet mappings if they exist.

• Validate your endpoint class structure
  Ensure your endpoint class properly implements the interface specified in endpointInterface of the @WebService annotation. A missing or incorrect implementation could cause the JAX-WS container to fail to recognize it as a valid endpoint, leading the container to misclassify it when other misconfigurations are present. Also, confirm the class is correctly compiled and present in WEB-INF/classes or the appropriate jar in WEB-INF/lib—a missing or corrupted class file could lead to unexpected loading behavior.

• Check IBM-specific deployment descriptors
  If you're using ibm-web-ext.xml or other WebSphere-specific config files, verify there are no settings forcing the class to be treated as a Servlet. For example, incorrect classloader settings or servlet mapping overrides in these files could trigger this error.

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