Develop Reference

Generate Java webservice based on ONVIF wsdl (Top Down Method)

I want to generate server code for a device like Camera. There is a standard protocol for these device called ONVIF which publish some popular WSDL documents. So I must generate an interface and skelton from ONFIV's WSDL documents.
When I use wsdl2java to generate server code from ONVIF wsdl file, it says:
org.apache.axis2.AxisFault: No services found in the WSDL at https://www.onvif.org/onvif/ver10/device/wsdl/devicemgmt.wsdl with targetnamespace http://www.onvif.org/ver10/device/wsdl
Is there a problem via these WSDL files?
How can generate Server code based on ONVIF WSDL?

I had a same problem in generating java classes from WSDL files in order to create ONVIF web server. After a great deal of investigation I found out there are some errors in WDSL files which I got form https://www.onvif.org
If you want to create java classes properly you need to make some changes on them.
First, in each .wsdl file check the correct path of schemaLocation , it may need to change to : schemaLocation="../../../ver10/schema/onvif.xsd"/>
And also check whether all .wsdl files have service tag like this.
<wsdl:service name="DeviceIOPService">
<wsdl:port name="DeviceIOPort" binding="tmd:DeviceIOBinding">
<soap:address location="http://www.onvif.org/ver10/deviceIO/wsdl"/>
</wsdl:port>
</wsdl:service>
If they don't have , create for them, then run generating command.
If you need further information, inform me.

If you go the link https://www.onvif.org/onvif/ver10/device/wsdl/devicemgmt.wsdl as you specified for wsdl2java you hit a HTML page you are not getting a WSDL file. See the screenshot below:
The HTML document is actually a valid WSDL i.e. full xml document but it uses a XSLT to transform the XML to HTML for display and this creates a bit of problem for wsdl#java.
If you view the web page source and you remove the XSLT link code:
<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type="text/xsl" href="../../../ver20/util/onvif-wsdl-viewer.xsl"?>
Becomes:
<?xml version="1.0" encoding="utf-8"?>
Then you can load the WSDL into a WSDL editor and see the operations see screen shot below:
To get this working I would contact the Onvif group and ask them for the WSDL location as the WSDL contains links to XSD files which you will need as well. The current location cannot be used as is.

Error in using custom wsdl with axis2 [duplicate]

I have followed contract first approach. So I first wrote the wsdl file and then generated the server side code. But when I hit the url for my web service in the browser then I see the auto generated wsdl file; not the one I had kept inside META-INF folder. I have also set useOriginalwsdl=true in my services.xml file. When I try to view the wsdl in browser, it fires error
Unable to generate WSDL 1.1 for this service in description section and
If you wish Axis2 to automatically generate the WSDL 1.1, then please set useOriginalwsdl as false in your services.xml in the reason section of error tag.
Please help me.

useOriginalwsdl=true will work if you have followed the following steps:
put the custom wsdl file inside the META-INF folder.
the service name should be the same in both the custom wsdl as well as in the services.xml
Name the custome wsdl as service.wsdl or (Your ServiceName).wsdl.
Set useOriginalwsdl=true in services.xml file
Note: If useOriginalwsdl=true, Axis2 engine first tries to use any wsdl file named service.wsdl. If not found, then it tries to find named (your service name).wsdl
If not succeeds, then it shows error when u try to access the web service.

Do you have external schema references in your WSDL..? If so, those should be also added to META-INF directory... Please also attach your WSDL..
Since you are using contract first, better you validate your WSDL too.. there are wsdl validating tools available...
Thanks...

Accessing SOAP web service with incorrect wsdl

Background:
I need to consume an existing web service (SOAP over http) that has a couple of issues:
1) The wsdl on the server doesn't even resemble the web service as described in their documentation, which includes a completely different wsdl file
2) The wsdl file provided with their documentation seems to come close to describing the web service on the server, but when I generated java client code using cxf and used it to access the web service, cxf throws exceptions like the following
javax.xml.bind.UnmarshalException: unexpected element (uri:"http://us-labs.companyxyz.com/", local:"searchResponse"). Expected elements are <{http://companyxyz.com/xyz-xml/2.0/}searchResponse>
... 33 more
I'm no SOAP expert, but assuming this means the namespaces in their response don't match those defined in the wsdl.
Since my application is written in java, I was able to connect and get a response using commons http client and a handcrafted SOAP request, so worst case I can fall back to that and parse the response to get what I need.
My questions:
Did I interpret the exception correctly?
If no: any suggestions on how I can debug this?
If yes: can anyone suggest better alternatives to handcrafting http requests and parsing xml by hand? (Getting correct wsdl is, unfortunately, not an option)
Thanks in advance.

Most likely. The response is using the namespace "http://us-labs.companyxyz.com/", but in the WSDL, the same element is declared with namespace "http://companyxyz.com/xyz-xml/2.0/".
I'm not familiar with CXF, but other SOAP frameworks usually offer some kind of logging capabilities. It would probably help you if the SOAP requests and responses are logged somewhere for more specific analysis.
Why is it not an option to get a correct WSDL? If you really are able to "handcraft" correct SOAP requests and expect to be able to "handparse" the responses, you should be able to write the WSDL yourself as well. Of course, the WSDL should be provided to you by the service operator, but if you mean that noone is able to provide you with a correct WSDL, I would consider writing it myself instead of creating and parsing the SOAP messages manually.

I think you interpreted the exception correctly - the namespace is different than expected.
It is also not really unexpected. it is a fact of life that vendor supplied wsdls are not always correct. We actually write our own WSDLs and XSDs for vendor applications for just that reason.
You can use your own WSDL even run-time. There are some SO questions on that, here and here.
You could also have a look here. I haven't tried it, but it could work.
We actually extend the generated service and create a port supplying a WSDL located on the classpath using the JaxWS Service constructor. That works fine for us.
We debug CXF by dumping the incoming and outgoing messages. There seem to be quite a lot of methods to do just that. We use either a proxy between de web service and our client, or recently a cxf.xml file somewhere. Using a -D flag we temprarily configure this.
-Dcxf.config.file=/home/me/cxf-debug.xml
and cxf-debug.xml contains something like:
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:cxf="http://cxf.apache.org/core"
xsi:schemaLocation="
http://cxf.apache.org/core http://cxf.apache.org/schemas/core.xsd
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd">
<cxf:bus>
<cxf:features>
<cxf:logging/>
</cxf:features>
</cxf:bus>
</beans>
http://cxf.apache.org/docs/debugging-and-logging.html

Both responses suggested the same basic approach, which turned out to be the correct one.
I fixed the provided wsdl to make it match the web service, and I was able to use cxf, which saved me a lot of hand coding.
The main problem with their wsdl was in fact a namespace issue. The essence of the problem was as follows: their wsdl defined two namespaces, both of which have a "searchResponse" element.
{http://us-labs.companyxyz.com/}searchResponse
was defined in the wsdl to contain 0 or more
{http://companyxyz.com/xyz-xml/2.0/}searchResponse
But in their response the nested searchResponse wasn't qualified by {http://companyxyz.com/xyz-xml/2.0/} so cxf interpreted it as a {http://us-labs.companyxyz.com/}searchResponse
I fixed it by introducing a new type.
Thanks to both responders.

CXF Client Side Duplication of targetnamespace

I am hosting a webservice and a webapp on the same server, generated from wsdl2java. I can contact the service just fine through SoapUI and it returns a single namespace declaration when posted to the live server, but when I am working locally and use SoapUI it generates two instances of xlmns="" instead of a single one in my xml. I have copied below an example xml file:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body>
<SendResponse xmlns="http://myendpoint.org/service" xmlns:ns2="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<Receipt>
<MyReceipt xmlns:ns3="http://myendpoint.org/service" xmlns="" xmlns="" xmlns:ns6="http://myapp.myserver.net/myservicegroup/myservice/V01" receiptVersion="V01">
<ReceiptHeader>
<ReceiptTimestamp>2010-04-13T08:27:03.036-04:00</ReceiptTimestamp>
</ReceiptHeader>
<TransmissionReceipt>
<TransmissionID>testuser</TransmissionID>
<TransmissionTimestamp>2010-04-13T08:27:03.036-04:00</TransmissionTimestamp>
</TransmissionReceipt>
</MyReceipt></Receipt></SendResponse></soap:Body></soap:Envelope>
So when it unmarshalls, it fails badly when I use my webapp as a webservice client. Why is CXF adding a second namespace? I watched the debug all the way through until the return and it looked 100% perfect on the webservice side, no duplicate name space at all. It does not happen until the return of the xml to the client side.

In XML, attributes are unique to each element, so if this occurs then it is probably a bug and you should report it as such. I've worked with CXF before and it's a great library, but it's unfortunately not perfect. I had to mess around with various versions, upgrading to an unstable one to get around the bugs I encountered.
W3C XML Spec
An attribute name MUST NOT appear more than once in the same start-tag or empty-element tag.

How do I interpret a WSDL with references to a namespace java: on a non-java client?

I'm trying to integrate against a SOAP web service, running on Apache Axis. The WSDL specifies a namespace with a URI, that looks like:
<xsd:schema
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:stns="java:dk.tdc.serviceproviderweb.datatypes"
elementFormDefault="qualified"
attributeFormDefault="qualified"
targetNamespace="java:dk.tdc.serviceproviderweb.datatypes">
On the client-side, I'm using PHP, so the namespace xmlns:stns is meaningless. I have some Java class files (and their sources), that seems to correspond to this namespace. How do I handle this in a meaningful way?

OK. It seems that I got confused by the fact that my client library had a bug, which made it choke on the wsdl. I switched from NuSOAP to php5's native soap library, and things works now.

Your snippet is the beginning of an XML schema that defines the contents of the "java:dk.tdc.serviceproviderweb.datatypes" namespace. (The targetNamespace attribute indicates this).
So it shouldn't matter if you're handling this with java or PHP on the client side,
as long as the rest of this schema is valid.