How to Find and Configure the WSDL URL of my WebService

Despite the dominance of RESTful APIs (Jakarta REST) and gRPC in greenfield microservice designs, SOAP Web Services (Jakarta XML Web Services, formerly JAX-WS) remain a critical pillar in mission-critical enterprise systems, government integrations, banking middleware, and legacy telecommunication backbones.

When deploying SOAP endpoints to WildFly 41—powered by the integrated JBossWS-CXF 7.x stack—identifying the exact endpoint contract (WSDL) URL is the primary prerequisite for integration testing with tools like SoapUI, Postman, or automated CI/CD validation suites. Here is an updated guide covering discovery, runtime inspection, and container-friendly address rewriting.

1. Server Boot Log Inspection

When you deploy an archive containing a Jakarta Web Service (e.g., account-service.war), the WildFly CXF integration logger (org.jboss.ws.cxf.metadata) logs the bound addresses directly to standalone/log/server.log:

The operational WSDL endpoint is accessible by appending ?wsdl to the logged address parameter:

http://localhost:8080/account-service/AccountServiceWS?wsdl

2. Querying Endpoints via JBoss CLI (Automation Friendly)

For automated pipelines, health probes, or headless server instances, the JBoss CLI provides unified access to runtime metadata without requiring log scraping.

Query a specific endpoint

Query all active SOAP endpoints simultaneously

You can execute a wildcard query across all active deployments to collect names, WSDL URLs, and operational metrics (request counts, fault counts, and processing times):

CLI Output structure:

3. Inspecting via the HAL Web Console

If you prefer a graphic interface:

1. Access the WildFly Management Console at http://localhost:9990/console/.
2. Navigate to Runtime in the top-level menu bar.
3. Select your current standalone server (or target managed server in Domain Mode).
4. Under the Subsystems sidebar on the left, click Web Services.
5. The panel displays every deployed service along with its direct WSDL URL link.

4. How WildFly Generates and Rewrites the WSDL Address

In a code-first approach, the WSDL definition is derived directly from the endpoint implementation and its annotations:

Inside the generated WSDL, the service binding declaration exposes the physical connection string:

Dynamic Address Rewriting in Cloud & Container Scenarios

When running WildFly 41 behind a reverse proxy, TLS-terminating load balancer, or Kubernetes Ingress controller (e.g., Traefik, NGINX, AWS ALB), the internal host (localhost:8080 or pod IP) must not be leaked to public clients inside the WSDL. WildFly handles this via address rewriting.

In standalone.xml under the webservices subsystem, address modification is enabled by default:

• modify-wsdl-address: Defaults to true. When enabled, WildFly rewrites the <soap:address location="..."> value using the server runtime host or configured override. If set to false, the literal address string present in the packaged WSDL file is served unaltered.
• wsdl-host: Forces CXF to replace the hostname in the contract. You can pass system properties dynamically: <wsdl-host>${env.PUBLIC_HOSTNAME:localhost}</wsdl-host>.

5. Application-Level Overrides: jboss-webservices.xml

If you have multiple applications on the same WildFly instance requiring different hostnames or protocol specifications, you can configure overrides inside the deployment archive using WEB-INF/jboss-webservices.xml (for WARs) or META-INF/jboss-webservices.xml (for EJB JARs):

6. Contract-First (Top-Down) Storage Location

When implementing bottom-up (code-first) endpoints, WildFly generates the schema definitions and stores a copy of the synthesized WSDL locally within its internal data directory:

For top-down (contract-first) designs where your WSDL is packaged inside the deployment archive (e.g., WEB-INF/wsdl/AccountService.wsdl), bind it explicitly using the wsdlLocation attribute to avoid runtime dynamic generation:

Summary & Best Practices

• Immediate Verification: Query /deployment=*/subsystem=webservices/endpoint=*:read-resource(include-runtime=true) via CLI after deployment.
• Behind TLS Reverse Proxies: Always verify that wsdl-host and wsdl-secure-port match your public domain so consumers downloading the WSDL do not receive internal container IPs or insecure http:// endpoints.
• Modernization Note: For new systems, consider exposing lightweight REST endpoints via Jakarta RESTful Web Services (RESTEasy) or gRPC alongside SOAP endpoints using common business delegate layers.