How do I include a packaged WSDL to use with Java classes generated with wsimport?

Question

I'm coming from C# so I realize that I can't expect a lot of the (great) usability features and functionality to be there in Java, but I've been sort of put on this Java project recently and I simply cannot figure this out. In C# / .NET making web service proxy classes and generated data contracts was pie but for some reason the Java implementation of web services just doesn't seem right to me.

Here's the deal...

I use wsimport to create the generated .java files from .wsdl files. For example...

"%JAVA_HOME%\bin\wsimport" -quiet -extension -s .\src -d .\bin ".\wsdl\MyWSDL.wsdl"

I noticed that this hard-coded (typing that phrase almost made me vomit just now) "wsdlLocation" as the current location of the wsdl ("C:\Users\ME\etc\wsdl\MyWSDL.wsdl"). So I take it out:

"%JAVA_HOME%\bin\wsimport" -quiet -extension -s .\src -d .\bin -wsdllocation "NULL" ".\wsdl\MyWSDL.wsdl"

Now when I instantiate a generated service...

MyService xyz = new MyService();

I get an error. Something along the lines of "can't find file C:\blahblah\Temp\NULL" . OK... back to the drawing board. After having investigated this a little, I found a post here on Stack Overflow that talked about using "classpath:META-INF/WSDL.wsdl" as the wsdl location.

"%JAVA_HOME%\bin\wsimport" ... -wsdllocation "classpath:WSDLs/MyWSDL.wsdl" ".\wsdl\MyWSDL.wsdl"
copy ".\wsdl\*" .\bin\WSDLs
cd bin
"%JAVA_HOME%\bin\jar" cf WebServiceProxies.jar *

Error!

"Unknown protocol: classpath" 

Strangely enough, the post on Stack Overflow was marked as the answer. I guess it's possible that over the last two years a decent amount has changed to the point where "classpath:" is no longer supported or there is another method of doing this but I haven't been able to figure it out / find the answer.

OK, so I have one of several questions I need answered (thanks in advance!!!! I'm going nuts over here!).

1. Is there a way for it to NOT NEED the WSDL at runtime? For what it's worth, I think it's B.S. that it needs this when I instantiate objects. Any way to suppress this requirement? Maybe if I used a different tool...?

2. If there is NO WAY for this code to not need the WSDL at runtime, how do I get it to pick up this WSDL from the package? What do I put in the wsdllocation argument to make it load the WSDL from within the JAR file?

Answer 1

Since the need-for-wsdl-at-runtime-tragedy never bothered me, I have no answers on #1. That said, the use of packaged wsdl should be a last resort anyways. I prefer to use the published wsdl endpoint. So the actual wsdl location would be http(s)://host/name_of_service?wsdl for most hosting frameworks or http(s)://host/name_of_service.wsdl for spring-ws.

As for the complexity of java-based webservice client programming, let me show you a small excerpt from one of my maven based projects:

<plugin>
    <groupId>org.apache.cxf</groupId>
    <artifactId>cxf-codegen-plugin</artifactId>
    <version>2.6.1</version>
<executions>
    <execution>
        <id>generate-sources</id>
        <phase>generate-sources</phase>
        <configuration>
            <sourceRoot>${project.build.directory}/generated-sources/cxf</sourceRoot>
            <wsdlOptions>
                <wsdlOption>
                    <wsdl>https://XXXXXXXX/ws/loadsave?wsdl</wsdl>
                </wsdlOption>
            </wsdlOptions>
        </configuration>
        <goals>
            <goal>wsdl2java</goal>
        </goals>
    </execution>
</executions>

Maybe I'm not too IDE-centric, but it seems pretty simple for me. Apache CXF is one of the best webservice stacks out there. (although for documentation I use Fuse http://fusesource.com/docs/esb/3.5/fsf_se/JAXWSWSDLFirst.html . It's basically CXF rebranded with much better documentation.)

Hope that answers your question (at least partially).

on the java rant: I don't use MS tools unless I have to, but not because I hate them. My work somehow pushed me towards bigger projects and it's quite rare to see .net support on high-end (or even mid-range for that matter) servers. It's just a fact, that won't make java better then .net. But I'm pretty sure if I have to work on MS stuff I would get used to it pretty fast. So my advice is: be happy that your work gave you a possibility to learn something new and cherish it. In the end we're in this business because we like to learn new things I guess.