5

I have a web service that was created several years ago in C++ and is consumed by a .NET client using C#'s "wsdl.exe" to generate the client stubs. For a variety of reasons, I now also need a Java client and am willing to restrict usage to Java 6 (JDK 1.6) with JAX-WS. The generated stubs work fine, even when packaged in a .jar, but I'm having a problem with the way that JAX-WS web service clients want to be deployed. It looks like the problem I'm having is solvable, but none of the suggested ways seems to work.

JAX-WS expects the WSDL to be accessible, preferably from the network, as it parses the WSDL on startup every time to create the bindings. Like jgrowl in Creating a web-service client with a known but inaccessible wsdl, the client may not have access to the WSDL at the URL that JAX-WS uses (which will likely be a file on the build machine or a pointer to localhost). I want to ship the WSDL inside the client .jar, but the simplest solution (-wsdllocation "/path/to/wsdl/in/jar.wsdl") prints out a warning that I do not want to show up.

I would also prefer not having the client do something like the solution jgrowl found, which appears to work but doesn't Just Work. Articles found on Google mostly address server WSDL locations, but suggest that clients should be able to work with META-INF/jax-ws-catalog.xml files that translate the URL used in -wsdllocation to a path in the .jar file, but those do not seem to work in our testing.

Is there a "recipe" so that I can put the WSDL inside the .jar somewhere and have a JAX-WS client just work with no extra effort on the part of the client user and with no warnings?

Community
  • 1
  • 1
Austin Ziegler
  • 776
  • 10
  • 17

1 Answers1

3

If you prefer not to set the URL to the WSDL in the constructor, you might be able to rely on the behaviour of the generated artifacts. When I use the following -wsdlLocation:

-wsdllocation wsdl/MaintainAddress.wsdl

The following is generated in the service code as a static initializer:

static {
    URL url = null;
    try {
        URL baseUrl;
        baseUrl = demo.ws.service.MaintainAddress_Service.class.getResource(".");
        url = new URL(baseUrl, "wsdl/MaintainAddress.wsdl");
    } catch (MalformedURLException e) {
        logger.warning("Failed to create URL for the wsdl Location: 'wsdl/MaintainAddress.wsdl', retrying as a local file");
        logger.warning(e.getMessage());
    }
    MAINTAINADDRESS_WSDL_LOCATION = url;
}

This will essentially do the same thing as the solution you found, but with the default constructor. The WSDL needs to be a resource on the classpath in the the wsdl folder.

This approach issues no warnings for me.

I don't think this behaviour is defined in the spec - at least, I haven't been able to find it. I believe it is an implementation detail of the wsimport tool in my JDK.

You have more options if you're deploying to a Java EE container - see JSR 109. I believe this is where jax-ws-catalog.xml comes into play.

McDowell
  • 107,573
  • 31
  • 204
  • 267
  • Unfortunately, doing `-wsdlLocation wsdl/MaintainAddress.wsdl` results in the warnings—at least when I tried it on Friday. That said, it appears that the `jax-ws-catalog.xml` stuff works as of today. Colour me baffled. – Austin Ziegler May 09 '11 at 18:20
  • Can you update/answer your question with jax-ws-catalog.xml solution? I envision myself to run into the same issue in a foreseeable future... thanks! – Vladimir Dyuzhev May 09 '11 at 19:43
  • @Austin Ziegler - it might help if you state what the warning message is. – McDowell May 09 '11 at 19:53
  • The warning is the "Failed to create URL for the wsdl location" handle by the try/catch in the block. I'll go through the steps that we tried again last week to update this with more detail and also verify that the jax-ws-catalog.xml solution works. It's in code review right now. – Austin Ziegler May 10 '11 at 13:53
  • @AustinZiegler could you update your final solution? We run into same issue. Thanks. – Lee Feb 10 '17 at 19:35
  • Unfortunately, I don’t recall what was done, and I haven’t the access to the code in question as I haven’t worked at the place where I ran into this for almost six years. I *think* that I resolved it using the `jax-ws-catalog.xml` options described in JSR 109 and the above comment. I will mark it as accepted because it seems like it was mostly, if not completely, right. – Austin Ziegler Feb 12 '17 at 00:56