0 or null return values when .Net client accesses JBoss webs

[md5georg]

Hello,

We are currently developing an api that is exposed through doc/literal
web service methods and our customers are going to use their own
developed .Net clients to access it. We are now testing this api from a .Net VB client.

Connection and access between the client and server is now up and
running, and both complex types and primitive values are sent from the
.Net client to the server. On the way back though, no values for either
complex types or primitives are showing up at the client. It feels like the
client is unable to deserialize the client value.

I have searched the net for information about this and the only thing that
seams to fit this problem have something to do with qualified/unqualified
'form' attribute on the element description for the getBurro3Response...
but I can not find any information about this here on the JBoss forums.

If anyone have seen this problem before I would be grateful for any ideas
about what could be wrong.

(This post will also be posten in some Microsoft .Net forum, since I suspect
that it is a .Net client error)


Best regards,

Georg



Soap call:

POST /ports/TacoBell HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 1.0.3705.6018)
Content-Type: text/xml; charset=utf-8
SOAPAction: ""
Content-Length: 337
Expect: 100-continue
Connection: Keep-Alive
Host: 127.0.0.1

<?xml version="1.0" encoding="utf-8"?>
 <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
 <soap:Body>
 <getBurro3 xmlns="http://bullen.com/fleet/api/types">
 <int_1>12</int_1>
 </getBurro3>
 </soap:Body>
 </soap:Envelope>

Soap response:

HTTP/1.1 100 Continue

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
X-Powered-By: Servlet 2.4; JBoss-4.0.2RC1 (build: CVSTag=JBoss_4_0_2_RC1 date=200503140913)/Tomcat-5.5
Content-Type: text/xml;charset=utf-8
Transfer-Encoding: chunked
Date: Mon, 21 Mar 2005 12:43:04 GMT

196
<?xml version="1.0" encoding="UTF-8"?>
 <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <soapenv:Body>
 <ns1:getBurro3Response xmlns:ns1="http://bullen.com/fleet/api/types">
 <result>heppadoda!</result>
 </ns1:getBurro3Response>
 </soapenv:Body>
 </soapenv:Envelope>
0

Here is the part from the WSDL file that handles the getBurrito3Response:

<?xml version="1.0" encoding="UTF-8"?>
<definitions name="FleetAPI" targetNamespace="http://bullen.com/fleet/api" xmlns:tns="http://bullen.com/fleet/api" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:ns2="http://bullen.com/fleet/api/types" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns="http://schemas.xmlsoap.org/wsdl/">
 <types>
 <schema attributeFormDefault="qualified" elementFormDefault="qualified" targetNamespace="http://bullen.com/fleet/api/types" xmlns="http://www.w3.org/2001/XMLSchema" xmlns:soap11-enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns="http://bullen.com/fleet/api/types" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

...

 <complexType name="getBurro3Response">
 <sequence>
 <element name="result" nillable="true" type="string"/></sequence></complexType>

[jason.greene]

"md5georg" wrote:

<?xml version="1.0" encoding="UTF-8"?>
 <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <soapenv:Body>
 <ns1:getBurro3Response xmlns:ns1="http://bullen.com/fleet/api/types">
 <result>heppadoda!</result>
 </ns1:getBurro3Response>
 </soapenv:Body>
 </soapenv:Envelope>

This appears to be a bug in ws4ee, the above instance document is not schema valid because, your wsdl sets elementFormDefault="qualified" so "result" should be qualified, and its not.

Could you submit a jira bug report on this http://jira.jboss.org with an example?

Also to work around the problem, is there anyway you can set elementFormDefault and attributeFormDefault to unqualified? (This will probably resolve the issue)

Thanks,
-Jason

[md5georg]

Hello,

thanks for the reply jasong!

I am very sorry... the included WSDL part was not correct. It should not contain the "qualified" attributes should not be there. I did copy the part from the wrong WSDL file. The correct WSDL should be like this (again, I am sorry :) :

<?xml version="1.0" encoding="UTF-8"?>
<definitions name="FleetAPI" targetNamespace="http://bullen.com/fleet/api" xmlns:tns="http://bullen.com/fleet/api" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:ns2="http://bullen.com/fleet/api/types" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns="http://schemas.xmlsoap.org/wsdl/">
 <types>
 <schema targetNamespace="http://bullen.com/fleet/api/types" xmlns="http://www.w3.org/2001/XMLSchema" xmlns:soap11-enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns="http://bullen.com/fleet/api/types" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

...

 <complexType name="getBurro3Response">
 <sequence>
 <element name="result" nillable="true" type="string"/></sequence></complexType>

By the way, what does it mean, qualified/unqualified and how did you see that the SOAP request was not qualified?


Best regards,

Georg

Ps. I tried even though to set them "unqualified" but then the client could not even parse the WSDL file... Jikes! ds.

[jason.greene]

"md5georg" wrote:
Hello,

thanks for the reply jasong!

I am very sorry... the included WSDL part was not correct. It should not
contain the "qualified" attributes should not be there. I did copy the part
from the wrong WSDL file. The correct WSDL should be like this (again, I
am sorry :) :

Well then the response message is correct, since the default is unqualified.
I am not sure what problem .NET would have with it then. One thing that
is missing though from your wsdl snippet is your element definition. Would
you mind posting your full wsdl file, or perhaps the element definition for
getBurro3Response?

Also, this could potentially be a bug in how .NET generates the client code.
Can you search your generated client code for
"Form=System.Xml.Schema.XmlSchemaForm.Qualified", you may have to
edit this to fix the problem.

By the way, what does it mean, qualified/unqualified and how did you see
that the SOAP request was not qualified?

Prefixed = foo:b
Non-prefixed = b
Qualified = element is declared to be in a namespace via a default
namespace declaration ie xmlns="blah" on the tag or it is prefixed (foo:b).
Unqualified = local scoping, element has no namespace. Usually this is a
non-prefixed element where its parent element has no default namespace.

So result is unqualified ns1:result is qualified.

For more info see the primer http://www.w3.org/TR/xmlschema-0

-Jason

Ps. I tried even though to set them "unqualified" but then the client could
not even parse the WSDL file... Jikes! ds.

hmm thats very bad, you may have another error in the file whats your validation error?

-Jason

[md5georg]

Hello again,

thanks for all your effort!

I think I should mention that the WSDL file is generated from SEI's with wscompile -f:documentliteral.

We have searched the generated .NET code but found no "Form=System.Xml.Schema.XmlSchemaForm.Qualified" (or "Unqualified").

Here is all code from the WSDL file that reflects the getBurro3 and its response structure:

<?xml version="1.0" encoding="UTF-8"?>
<definitions name="FleetAPI" targetNamespace="http://bullen.com/fleet/api"
xmlns:tns="http://bullen.com/fleet/api"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:ns2="http://bullen.com/fleet/api/types"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/">

 <types>
 <schema targetNamespace="http://bullen.com/fleet/api/types"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:soap11-enc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:tns="http://bullen.com/fleet/api/types"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">


...

 <complexType name="getBurro3Response">
 <sequence>
 <element name="result" nillable="true" type="string"/></sequence></complexType>

 <complexType name="getBurro3">
 <sequence>
 <element name="int_1" type="int"/></sequence></complexType>


...

 <element name="getBurro3Response" type="tns:getBurro3Response"/>
 <element name="getBurro3" type="tns:getBurro3"/>
 </types>

...

 <message name="TacoBellService_getBurro3Response">
 <part name="result" element="ns2:getBurro3Response"/></message>

 <message name="TacoBellService_getBurro3">
 <part name="parameters" element="ns2:getBurro3"/></message>

...

 <operation name="getBurro3">
 <input message="tns:TacoBellService_getBurro3"/>
 <output message="tns:TacoBellService_getBurro3Response"/></operation>

...

 <binding name="TacoBellServiceBinding" type="tns:TacoBellService">
 <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document"/>

 <operation name="getBurro3">
 <soap:operation soapAction=""/>
 <input>
 <soap:body use="literal"/></input>
 <output>
 <soap:body use="literal"/></output></operation>


...

 <port name="TacoBellServicePort" binding="tns:TacoBellServiceBinding">

Can you see any problems with this WSDL snippet?


Something that strikes me as really odd is the usage of wscompile's -f:wsi flag.
When reading about it on the jwsdp-1.5 tools side:

"The wscompile tool reads as input either a WSDL file, compiled service endpoint interface (SEI), or model file. The Type of File column indicates which of these files can be used with a particular feature."
Which is the last column.

"wsi", "enable WSI-Basic Profile features, to be used for document/literal and rpc/literal", "WSDL"

so, here the WSDL file should be the input? ...but when reading on this page (under "Solution"):

https://bpcatalog.dev.java.net/nonav/soa/dotnet-client/ (claimed Sun page)

it feals like -f:wsi is passed when creating the WSDL from SEI's.

Maybe you can sheed some light about this issue also?


Best regards,

Georg

[md5georg]

This problem has now been resolved after much elaboration.
On the client side we had Visual Studio 2002 which uses .Net 1.0. When we
uppgrade it to Visual Studio 2003 which uses .Net 1.1 things started
to work.

Thanks jasong for all your help!


Best regards,

Georg