SOAPFaultException: Unmarshalling Error: unexpected element (uri:"", local:"tagName")
Ivan Pazmino
Greenhorn
Posts: 6
posted 4 years ago
Hello,
In order to consume some WS I have generated the client using the JAX-WS RI tool and generated the service, port and operation responses out of the wsdl.
The service is being reached and the port is being returned, but when I try to call the operation I get the following exception
javax.xml.ws.soap.SOAPFaultException: Unmarshalling Error: unexpected element (uri:"", local:"tagName"). Expected elements are <{http://com.ws.namespace}tagName>
when creating the service I am setting the namespaceURI and the local part
At the generated objetcFactory the namespace is also present
And the namespace is also declared into the package-info file
What could be wrong?
Thanks in advance.
IP
In order to consume some WS I have generated the client using the JAX-WS RI tool and generated the service, port and operation responses out of the wsdl.
The service is being reached and the port is being returned, but when I try to call the operation I get the following exception
javax.xml.ws.soap.SOAPFaultException: Unmarshalling Error: unexpected element (uri:"", local:"tagName"). Expected elements are <{http://com.ws.namespace}tagName>
when creating the service I am setting the namespaceURI and the local part
At the generated objetcFactory the namespace is also present
And the namespace is also declared into the package-info file
What could be wrong?
Thanks in advance.
IP
Hikari Shidou
Ranch Hand
Posts: 88
posted 4 years ago
-
1
-
-
-
-
As you can see, your client is expecting a TagName element but is receiving a uri one.
I had a similar problem. WebService provider was noob and using even noober outsourcers to develop his WebService. Instead of providing the WSDL from withing the WS, he sent it by email (yes...), and the fun part is that it was wrong, maybe outdated.
In the provided WSDL, operation was named "Create", but WebService was returning error message asking for "Novo". We changed the word in WSDL and were able to send the message, but client was getting error. By using Apache HTTP Monitor I saw that server was responding "correctly", but its response envelope had "Create"... I then went back to WSDL, renamed response message back to "Create", rebuilt client once more, and it worked... -.-*
Don't even try to fix your error. Use Axis2. Eclipse has built-in support for it, just install it and configure Eclipse to find it. Point Axis2 wizard to original WSDL and get client going. If error persists, use HTTP Monitor to see request and response messages. It seems your error happens when unmarshalling response, so you'll be able to compare response evelope with what WSDL defines. It it's different only in names, you can try to copy WSDL to HD and edit it to try to match what server is sending.
But if you get a proof that server response isn't compliant with its own WSDL (shame!) just call provider and DEMAND him to fix it. It's not client developer duty to guess over wrong WSDL definitions and blindly try to marshall and unmarshall XML messages that server will understand.
I had a similar problem. WebService provider was noob and using even noober outsourcers to develop his WebService. Instead of providing the WSDL from withing the WS, he sent it by email (yes...), and the fun part is that it was wrong, maybe outdated.
In the provided WSDL, operation was named "Create", but WebService was returning error message asking for "Novo". We changed the word in WSDL and were able to send the message, but client was getting error. By using Apache HTTP Monitor I saw that server was responding "correctly", but its response envelope had "Create"... I then went back to WSDL, renamed response message back to "Create", rebuilt client once more, and it worked... -.-*
Don't even try to fix your error. Use Axis2. Eclipse has built-in support for it, just install it and configure Eclipse to find it. Point Axis2 wizard to original WSDL and get client going. If error persists, use HTTP Monitor to see request and response messages. It seems your error happens when unmarshalling response, so you'll be able to compare response evelope with what WSDL defines. It it's different only in names, you can try to copy WSDL to HD and edit it to try to match what server is sending.
But if you get a proof that server response isn't compliant with its own WSDL (shame!) just call provider and DEMAND him to fix it. It's not client developer duty to guess over wrong WSDL definitions and blindly try to marshall and unmarshall XML messages that server will understand.
