JAX-WS Loading WSDL from jar

Yes this is most definitely possible as I have done it when creating clients through javax.xml.ws.EndpointReference, a WS-A related class. I have added a classpath reference to the WSDL to the WS-A EndPointReference and the Metro implementation of JAX-WS loaded it just fine. Whether loading the WSDL from the WS-A EndPointReference or from a file or http URL, your JAX-WS implementation should use the same WSDL parsing code as all you are doing is resolving URLs.

The best approach for you is probably to do something like the following:

URL wsdlUrl = MyClass.class.getResource(
            "/class/path/to/wsdl/yourWSDL.wsdl");

Service yourService= Service.create(
            wsdlUrl,
            ...);

Where ... represents the QName of a WSDL service inside of your WSDL. Now the important thing to remember is that your WSDL needs to be complete and valid. This means that if your WSDL imports XSD files or other WSDLs, the URLs must be correct. If you included your imported WSDL and XSDs in the same JAR as the WSDL file, you should use relative URLs for the imports and keep all of your imports in the same JAR file. The JAR URL handler does not treat the relative URLs as relative with respect to the classpath but rather to relative within the JAR file so you cannot have imports in your WSDL that run across JARs unless you implement a custom URL handler and your own prefix to do classpath based resolution of the imports. If your WSDL imports external resources, that is OK, but you are signing yourself up for maintenance issues if those resources ever move. Even using a static copy of the WSDL from your classpath is contrary to the spirit of WSDL, Web services, and JAX-WS, but there are times when it is necessary.

Finally, if you embed a static WSDL, I suggest that you at least make the service endpoint configurable for testing and deployment purposes. The code to reconfigure the endpoint of your Web service client is as follows:

  YourClientInterface client = yourService.getPort(
            new QName("...", "..."),
            YourClientInterface.class);
  BindingProvider bp = (BindingProvider) client;
  bp.getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY,
                "http://localhost:8080/yourServiceEndpoint");

If your classpath has "." in it, then Class.getResource(".") will return the URL of the directory from which you executed the java command. Else, it will return a null. Adjust the wsdllocation accordingly.

An other answer is to use the

new Service(wsdllocation, servicename );

to get the Service Object.

This is how I solved the problem.

I stumbled upon the same issue. The JAXWS generate client code uses the MyService.class.getResource(".") trick to load the wsdl file... but after testing this only seems to work if the class file is in a directory on the filesytem. If the class file is in a JAR this call returns null for the URL.

It sounds like a bug in the JDK since if you build your URL like this:

final URL url = new URL( MyService.class.getResource( MyService.class.getSimpleName() + ".class"), "myservice.wsdl");

then it also works if the class and wsdl are bundled in a jar.

I guess most people will actually bundle in a jar!

No need to complicate anything, just use jar classloader

ClassLoader cl = SomeServiceImplService.class.getClassLoader();
SERVICE_WSDL_LOCATION = cl.getResource("META-INF/wsdls/service.wsdl");

Try it!

Here's my hack-y workaround.

I unpack the WSDL from the jar and write it to a file near the jar:

File wsdl = new File("../lib/service.wsdl");
InputStream source = getClass().getResource("resources/service.wsdl").openStream();
FileOutputStream out = new FileOutputStream(wsdl);

byte[] buffer = new byte[512];
int read;
while((read = source.read(buffer)) >= 0) {
    out.write(buffer, 0, read);
}

Then point the service classes to file:../lib/service.wsdl.

This works, but I'd appreciate if anyone can show me a more elegant solution.