开发者

Embedding the WSDL for a web service in a JAX-WS client .jar

开发者 https://www.devze.com 2023-03-04 20:43 出处:网络
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

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?


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.

0

精彩评论

暂无评论...
验证码 换一张
取 消