How to avoid the need to specify the WSDL location in a CXF or JAX-WS generated webservice client?

Java Problem Overview

When I generate a webservice client using wsdl2java from CXF (which generates something similar to wsimport), via maven, my services starts with codes like this:

@WebServiceClient(name = "StatusManagement", 
                  wsdlLocation = "c:/some_absolute_path_to_a_wsdl_file.wsdl",
                  targetNamespace = "http://tempuri.org/") 
public class StatusManagement extends Service {

    public final static URL WSDL_LOCATION;
    public final static QName SERVICE = new QName("http://tempuri.org/", "StatusManagement");
    public final static QName WSHttpBindingIStatus = new QName("http://tempuri.org/", "WSHttpBinding_IStatus");
    static {
        URL url = null;
        try {
            url = new URL("c:/some_absolute_path_to_a_wsdl_file.wsdl");
        } catch (MalformedURLException e) {
            System.err.println("Can not initialize the default wsdl from c:/some_absolute_path_to_a_wsdl_file.wsdl");
            // e.printStackTrace();
        }
        WSDL_LOCATION = url;
    }

The hardcoded absolute path really sucks. The generated class won't work in any other computer other than mine.

The first idea is to put the WSDL file (plus everything it imports, other WSDLs and XSDs) somewhere in a jar-file and classpath it. But we want to avoid this. Since all that thing was generated by CXF and JAXB based in the WSDLs and XSDs, we see no point in needing to know the WSDL at runtime.

The wsdlLocation attribute is intended to override the WSDL location (at least this is what i readed somewhere), and it default value is "". Since we are using maven, we tried to include <wsdlLocation></wsdlLocation> inside the configuration of CXF to try to force the source generator to leave the wsdlLocation blank. However, this simply makes it ignore the XML tag because it is empty. We did a really ugly shameful hack, using <wsdlLocation>" + "</wsdlLocation>.

This changes other places too:

@WebServiceClient(name = "StatusManagement", 
                  wsdlLocation = "" + "",
                  targetNamespace = "http://tempuri.org/") 
public class StatusManagement extends Service {

    public final static URL WSDL_LOCATION;
    public final static QName SERVICE = new QName("http://tempuri.org/", "StatusManagement");
    public final static QName WSHttpBindingIStatus = new QName("http://tempuri.org/", "WSHttpBinding_IStatus");
    static {
        URL url = null;
        try {
            url = new URL("" + "");
        } catch (MalformedURLException e) {
            System.err.println("Can not initialize the default wsdl from " + "");
            // e.printStackTrace();
        }
        WSDL_LOCATION = url;
    }

So, my questions are:

Does we really need a WSDL location even if all the classes were generated by CXF and JAXB? If yes, why?
If we do not really need the WSDL location, what is the proper and clean way to make CXF not generate it and avoiding it entirely?
What bad side effects we could get with that hack? We still can't test that to see what happens, so if someone could say in advance, it would be nice.

Java Solutions

Solution 1 - Java

I finally figured out the right answer to this question today.

<plugin>
	<groupId>org.apache.cxf</groupId>
	<artifactId>cxf-codegen-plugin</artifactId>
	<version>${cxf.version}</version>
	<executions>
		<execution>
			<id>generate-sources</id>
			<phase>generate-sources</phase>
			<configuration>	
				<sourceRoot>${project.build.directory}/generated-sources/cxf</sourceRoot>
				<wsdlOptions>
					<wsdlOption>
						<wsdl>${project.basedir}/src/main/resources/wsdl/FooService.wsdl</wsdl>
						<wsdlLocation>classpath:wsdl/FooService.wsdl</wsdlLocation>
					</wsdlOption>
				</wsdlOptions>
			</configuration>
			<goals>
				<goal>wsdl2java</goal>
			</goals>
		</execution>
	</executions>
</plugin>

Notice that I have prefixed the value in wsdlLocation with classpath:. This tells the plugin that the wsdl will be on the classpath instead of an absolute path. Then it will generate code similar to this:

@WebServiceClient(name = "FooService", 
                  wsdlLocation = "classpath:wsdl/FooService.wsdl",
                  targetNamespace = "http://org/example/foo") 
public class Foo_Service extends Service {

    public final static URL WSDL_LOCATION;

    public final static QName SERVICE = new QName("http://org/example/foo", "Foo");
    public final static QName FooSOAPOverHTTP = new QName("http://org/example/foo", "Foo_SOAPOverHTTP");
    static {
        URL url = Foo_Service.class.getClassLoader().getResource("wsdl/FooService.wsdl");
        if (url == null) {
            java.util.logging.Logger.getLogger(Foo_Service.class.getName())
                .log(java.util.logging.Level.INFO, 
                     "Can not initialize the default wsdl from {0}", "classpath:wsdl/FooService.wsdl");
        }       
        WSDL_LOCATION = url;
    }

Note that this only works with version 2.4.1 or newer of the cxf-codegen-plugin.

Solution 2 - Java

We use

wsdlLocation = "WEB-INF/wsdl/WSDL.wsdl"

In other words, use a path relative to the classpath.

I believe the WSDL may be needed at runtime for validation of messages during marshal/unmarshal.

Solution 3 - Java

For those using org.jvnet.jax-ws-commons:jaxws-maven-plugin to generate a client from WSDL at build-time:

Place the WSDL somewhere in your src/main/resources
Do not prefix the wsdlLocation with classpath:
Do prefix the wsdlLocation with /

Example:

WSDL is stored in /src/main/resources/foo/bar.wsdl
Configure jaxws-maven-plugin with <wsdlDirectory>${basedir}/src/main/resources/foo</wsdlDirectory> and <wsdlLocation>/foo/bar.wsdl</wsdlLocation>

Solution 4 - Java

In some cases, yes. If the WSDL contains things like Policies and such that direct the runtime behavior, then the WSDL may be required at runtime. Artifacts are not generated for policy related things and such. Also, in some obscure RPC/Literal cases, not all the namespaces that are needed are output in the generated code (per spec). Thus, the wsdl would be needed for them. Obscure cases though.
I thought something like would work. What version of CXF? That sounds like a bug. You can try an empty string in there (just spaces). Not sure if that works or not. That said, in your code, you can use the constructor that takes the WSDL URL and just pass null. The wsdl wouldn't be used.
Just the limitations above.

Solution 5 - Java

I was able to generate

static {
    WSDL_LOCATION = null;
}

by configuring pom file to have a null for wsdlurl:

    <plugin>
        <groupId>org.apache.cxf</groupId>
        <artifactId>cxf-codegen-plugin</artifactId>
        <executions>
            <execution>
                <id>generate-sources</id>
                <phase>generate-sources</phase>
                <configuration>
                    <sourceRoot>${basedir}/target/generated/src/main/java</sourceRoot>
                    <wsdlOptions>
                        <wsdlOption>
                            <wsdl>${basedir}/src/main/resources/service.wsdl</wsdl>
                            <extraargs>
                                <extraarg>-client</extraarg>
                                <extraarg>-wsdlLocation</extraarg>
                                <wsdlurl />
                            </extraargs>
                        </wsdlOption>
                    </wsdlOptions>
                </configuration>
                <goals>
                    <goal>wsdl2java</goal>
                </goals>
            </execution>
        </executions>
    </plugin>

Solution 6 - Java

Update for CXF 3.1.7

In my case I put the WSDL files in src/main/resources and added this path to my Srouces in Eclipse (Right Click on Project-> Build Path -> Configure Build Path...-> Source[Tab] -> Add Folder).

Here is how my pom file looks like and as can be seen there is NO wsdlLocation option needed:

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

And here is the generated Service. As can be seen the URL is get from ClassLoader and not from the Absolute File-Path

@WebServiceClient(name = "EventService", 
              wsdlLocation = "classpath:wsdl/FOO_SERVICE.wsdl",
              targetNamespace = "http://www.sas.com/xml/schema/sas-svcs/rtdm-1.1/wsdl/") 
public class EventService extends Service {

public final static URL WSDL_LOCATION;

public final static QName SERVICE = new QName("http://www.sas.com/xml/schema/sas-svcs/rtdm-1.1/wsdl/", "EventService");
public final static QName EventPort = new QName("http://www.sas.com/xml/schema/sas-svcs/rtdm-1.1/wsdl/", "EventPort");
static {
    URL url = EventService.class.getClassLoader().getResource("wsdl/FOO_SERVICE.wsdl");
    if (url == null) {
        java.util.logging.Logger.getLogger(EventService.class.getName())
            .log(java.util.logging.Level.INFO, 
                 "Can not initialize the default wsdl from {0}", "classpath:wsdl/FOO_SERVICE.wsdl");
    }       
    WSDL_LOCATION = url;   
}

Solution 7 - Java

Is it possible that you can avoid using wsdl2java? You can straight away use CXF FrontEnd APIs to invoke your SOAP Webservice. The only catch is that you need to create your SEI and VOs on your client end. Here is a sample code.

package com.aranin.weblog4j.client;
 
import com.aranin.weblog4j.services.BookShelfService;
import com.aranin.weblog4j.vo.BookVO;
import org.apache.cxf.jaxws.JaxWsProxyFactoryBean;
 
public class DemoClient {
    public static void main(String[] args){
        String serviceUrl = "http://localhost:8080/weblog4jdemo/bookshelfservice";
        JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
        factory.setServiceClass(BookShelfService.class);
        factory.setAddress(serviceUrl);
        BookShelfService bookService = (BookShelfService) factory.create();
 
        //insert book
        BookVO bookVO = new BookVO();
        bookVO.setAuthor("Issac Asimov");
        bookVO.setBookName("Foundation and Earth");
 
        String result = bookService.insertBook(bookVO);
 
        System.out.println("result : " + result);
 
        bookVO = new BookVO();
        bookVO.setAuthor("Issac Asimov");
        bookVO.setBookName("Foundation and Empire");
 
        result = bookService.insertBook(bookVO);
 
        System.out.println("result : " + result);
 
        bookVO = new BookVO();
        bookVO.setAuthor("Arthur C Clarke");
        bookVO.setBookName("Rama Revealed");
 
        result = bookService.insertBook(bookVO);
 
        System.out.println("result : " + result);
 
        //retrieve book
 
        bookVO = bookService.getBook("Foundation and Earth");
 
        System.out.println("book name : " + bookVO.getBookName());
        System.out.println("book author : " + bookVO.getAuthor());
 
    }
}

You can see the full tutorial here http://weblog4j.com/2012/05/01/developing-soap-web-service-using-apache-cxf/

Solution 8 - Java

Seriously, the top answer is not working for me. tried cxf.version 2.4.1 and 3.0.10. and generate absolute path with wsdlLocation every times.

My solution is to use the wsdl2java command in the apache-cxf-3.0.10\bin\ with -wsdlLocation classpath:wsdl/QueryService.wsdl.

Detail:

    wsdl2java -encoding utf-8 -p com.jeiao.boss.testQueryService -impl -wsdlLocation classpath:wsdl/testQueryService.wsdl http://127.0.0.1:9999/platf/testQueryService?wsdl

Solution 9 - Java

@Martin Devillers solution works fine. For completeness, providing the steps below:

Put your wsdl to resource directory like : src/main/resource
In pom file, add both wsdlDirectory and wsdlLocation(don't miss / at the beginning of wsdlLocation), like below. While wsdlDirectory is used to generate code and wsdlLocation is used at runtime to create dynamic proxy.
```
<wsdlDirectory>src/main/resources/mydir</wsdlDirectory>
<wsdlLocation>/mydir/my.wsdl</wsdlLocation>
```

Then in your java code(with no-arg constructor):

MyPort myPort = new MyPortService().getMyPort();

Here is the full code generation part in pom file, with fluent api in generated code.

<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jaxws-maven-plugin</artifactId>
<version>2.5</version>

<dependencies>
    <dependency>
        <groupId>org.jvnet.jaxb2_commons</groupId>
        <artifactId>jaxb2-fluent-api</artifactId>
        <version>3.0</version>
    </dependency>
    <dependency>
        <groupId>com.sun.xml.ws</groupId>
        <artifactId>jaxws-tools</artifactId>
        <version>2.3.0</version>
    </dependency>
</dependencies>

<executions>
    <execution>
        <id>wsdl-to-java-generator</id>
        <goals>
            <goal>wsimport</goal>
        </goals>
        <configuration>
            <xjcArgs>
                <xjcArg>-Xfluent-api</xjcArg>
            </xjcArgs>
            <keep>true</keep>
            <wsdlDirectory>src/main/resources/package</wsdlDirectory>
            <wsdlLocation>/package/my.wsdl</wsdlLocation>
            <sourceDestDir>${project.build.directory}/generated-sources/annotations/jaxb</sourceDestDir>
            <packageName>full.package.here</packageName>
        </configuration>
    </execution>
</executions>

Solution 10 - Java

I was able to produce autogenerated

    static {
        WSDL_LOCATION = null;
    }

with

    <wsdlLocation>null</wsdlLocation>

Though, the purpose of this seems limited for me.. I was trying to achieve as fast as possible short-living WS Client, minimizing initialization on svc = new MyService(); binding = svc.getMySoapPort();, but now I see

INFO: Creating Service {http://www.example.com/MyApi}MyApiService from class com.company.MyApiPortType

instead of

INFO: Creating Service {http://www.example.com/MyApi}MyApiService from WSDL ...

It seems, new MyService(); is costly anyway, so I must think on re-use of long-lived concurrent instance of it... So runtime parsing of WSDL will not be a problem then.

Content Type	Original Author	Original Content on Stackoverflow
Question	Victor Stafusa	View Question on Stackoverflow
Solution 1 - Java	Kyle	View Answer on Stackoverflow
Solution 2 - Java	BPS	View Answer on Stackoverflow
Solution 3 - Java	Martin Devillers	View Answer on Stackoverflow
Solution 4 - Java	Daniel Kulp	View Answer on Stackoverflow
Solution 5 - Java	raisercostin	View Answer on Stackoverflow
Solution 6 - Java	Mazy	View Answer on Stackoverflow
Solution 7 - Java	Niraj Singh	View Answer on Stackoverflow
Solution 8 - Java	jeiao	View Answer on Stackoverflow
Solution 9 - Java	Shafiul	View Answer on Stackoverflow
Solution 10 - Java	Volo Myhal	View Answer on Stackoverflow