How to disable SOAP Web Services in WildFly

This is a short, practical tutorial explaining how to disable Jakarta XML Web Services (formerly JAX-WS SOAP Web Services) from the WildFly application server. We will show you how to accomplish this either globally at the server-subsystem level or selectively at the individual application deployment level.

With the release of WildFly 41.0.1.Final and Jakarta EE 11, keeping your application server lean, performant, and secure is highly beneficial. If your modern enterprise integrations have transitioned fully to RESTful architectures (Jakarta RESTful Web Services) or gRPC, removing the legacy SOAP engine (powered by Apache CXF / JBossWS-CXF) reduces server startup times, optimizes memory consumption, and shrinks the security attack surface—which is particularly useful when deploying to containerized cloud environments like Kubernetes or OpenShift.

Disabling Jakarta XML Web Services at the Server Level

If you do not deploy any SOAP-based web services across your entire WildFly installation, the cleanest approach is to remove the webservices subsystem and its corresponding extension. This prevents the WildFly runtime from booting the JBossWS-CXF stack entirely.

To do this, start your WildFly instance, connect using the Management CLI (jboss-cli.sh or jboss-cli.bat), and execute the following command to remove the subsystem:

/subsystem=webservices:remove
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}

Next, remove the web services module extension to stop WildFly from registering the subsystem's configuration schemas and boot classes:

/extension=org.jboss.as.webservices:remove
{
    "outcome" => "success",
    "response-headers" => {"process-state" => "reload-required"}
}

Finally, issue a reload command to apply the changes without restarting the entire physical JVM process:

:reload

Disabling SOAP Web Services at the Deployment Level

If you have a shared WildFly server where some deployments require SOAP but you want to disable Jakarta XML Web Services processing for a specific application, you can control classloading and subsystem integration using a jboss-deployment-structure.xml descriptor. This file must be placed in the META-INF directory (for EAR files) or the WEB-INF directory (for WAR files).

Add the following configuration using the modern 1.3 namespace schema to completely exclude the webservices subsystem from your application deployment:

<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.3">
  <deployment>
     <exclude-subsystems>
        <subsystem name="webservices"/>
    </exclude-subsystems>
  </deployment>
</jboss-deployment-structure>

If your web application is packaged within an Enterprise Archive (EAR), you can selectively disable SOAP processing for specific web sub-deployments by referencing the sub-deployment module:

<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.3">
  <sub-deployment name="myapp.war">
     <exclude-subsystems>
        <subsystem name="webservices"/>
    </exclude-subsystems>
    <dependencies>
       <!-- Add other custom dependencies here -->
    </dependencies>
  </sub-deployment>
</jboss-deployment-structure>

To learn more about mastering this deployment descriptor and managing enterprise classloading, check out this practical article: Examples of jboss-deployment-structure.xml

Frequently Asked Questions (FAQs)