Getting CXF error: javax.xml.ws.WebServiceException: WSDL Metadata not available to create the proxy

Question

I have used CXF's wsdl2java to generate code from a WSDL file. I then build the code using the ant build xml file (also generated by CXF's wsdl2java).

When I run my code on my local Java 7 machine, all is well. When I run the code on a linux box in the cloud running Java 1.5, I get the following error:

javax.xml.ws.WebServiceException: WSDL Metadata not available to create the proxy,
either Service instance or ServiceEndpointInterface com.a.b.TheService should have
WSDL information

I've had a search around and I can't find any information that might explain the error in my scenario. I'm not sure where to start on this one. Can anyone shed any light?

I mentioned Java versions above as it is an obvious difference, but it may have nothing to do with the problem.

UPDATE : Adding in the code below as a result of Syon's request:

private static final String servicesNamespace = "http://www.serviceprovider.com/services/2009/03/02";
private static final String servicesNamespaceSchema = "http://www.serviceprovider.com/services/2009/03/02/schema";
private static String SERVICE_NAME = "TheService";
private QName SERVICE_QNAME;
private TheService m_theService;
...

SERVICE_QNAME = new QName(servicesNamespace, SERVICE_NAME);

I wrote this code quite some time ago, and at the time I wrote the comment below.
I've included it here in case it is helpful:

// The sample code creates an instance of the generated TheService_Service class.
// TheService_Service has references to the local WSDL file that it was generated from, and
// will report an error if it is not found. To prevent that error, we could:
// (1) ensure that the WSDL is available locally in the production environment in the location
//     referenced in the generated Java
// (2) generate the Java from the WSDL located on the web rather than local WSDL, meaning that
//     the WSDL referenced in the generated Java would be a URL to where it is located on
//     serviceproviders's web site.
// (3) Rather than create an instance of TheService_Service, just create an instance of its
//     super class, javax.xml.ws.Service, which has a static method to create an instance of it that
//     does not require the location of the WSDL to be passed to it.
// I am going to choose option (3). Option (2) is a close second.

Service service = Service.create(SERVICE_QNAME);
m_theService = service.getPort(TheService.class);   <-- Fails here

((BindingProvider)m_theService).getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, endpointAddress);

Binding binding = ((BindingProvider)m_theService).getBinding();
((SOAPBinding)binding).setMTOMEnabled(false);

Thanks,

Paul

Answer 1

To my knowledge, JAX-WS/CXF always requires the WSDL. Could it be that you have the WSDL included on the classpath somewhere on your local machine but not on your linux box?

Regardless, you should be able to fix this issue by using the Service.create(URL, QNAME) method. The URL needs to point to the WSDL, you can use either the web service endpoint + ?wsdl on the end, or save a copy of the WSDL locally and point to that instead.

In your comment you mention referencing the WSDL on the web being preferable. Personally I would store it locally as this will improve performance when calling the web service. The framework won't need to make a call over the network just to get the WSDL every time you create the proxy.

Answer 2

This happens if he web service uses authentication. The WSDL cannot be read until the user name and password have been entered...

Answer 3

Faced with the same problem, it turned out, I was missing these depedencies:

    <dependency>
        <groupId>org.apache.cxf</groupId>
        <artifactId>cxf-rt-transports-http</artifactId>
        <version>3.0.0</version>
    </dependency>
    <dependency>
        <groupId>org.apache.cxf</groupId>
        <artifactId>cxf-rt-frontend-jaxws</artifactId>
        <version>3.0.0</version>
    </dependency>

Just adding them to my classpath solved the problem.

Maybe you had them already in the classpath under Windows?