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

Solution 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.

Solution 2

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

Solution 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?

Comments

[user265330]

Thank you. I can't see that the WSDL is in the classpath on my local machine, but I followed your advice and I get further - so thank you very much for your help - but I am now getting another error. I realise that this is perhaps now off topic but as you seem to have more knowledge of CXF than most I have come across I am hoping you may be able to shed some light - I am getting java.lang.ClassCastException: com.sun.xml.ws.client.sei.SEIStub when doing ClientImpl cli = (ClientImpl)ClientProxy.getClient(m_theService);. ClientProxy and ClientImpl are in cxf-2.1.3.jar only I think.

[Syon]

A quick look around suggests that sun's libraries are loading before CXF. See here and the end of this post. So the solution seems to be that you need to modify your class loader settings to get CXF loaded first.

[user265330]

Thank you again. I had seen the first of those links you sent, but I just cannot figure out how to resolve. Is it that com.sun.xml.ws.client.sei.SEIStub is being loaded from somewhere it should not? The only place I can find that class on the whole machine is in jaxws-rt-2.1.4.jar in my JBoss lib folder.

[Syon]

It's being loaded from the right place, the issue is that jaxws-rt-2.1.4.jar is being loaded before cxf-2.1.3.jar, it needs to be the other way around. You might try changing your class load policy to Partent Last, or try putting the cxf-2.1.3.jar in the JBoss lib folder. Class loader issues aren't really my strong point, sorry.

[vlakov]

CXF does not require WSDL in runtime of your client. I also had the same error/exception as stated in question when I didn't have 'cxf-manifest.jar' in my CLASSPATH. 'cxf-manifest.jar' contains MANIFEST.MF with "Class-Path" attribute with all the 50+ jars of CXF.

[vlakov]

You can use java -verbose which will report where all the classes were found; in which jar files were the classes found. In this way I found out that the JAX classes were not loaded from CXF jar files but from Java built-in jars.