Not much else I can suggest, then, except to try capturing the exchange
with Tcpmon or something similar to see what's actually getting sent out
from each end.
I updated some of my performance test code to run with the 1.1.1 Axis2
release. This uses attributes pretty heavily, and it looks correct.
Here's a sample of the actual XML:
<soapenv:Body>
<results xmlns="http://seismic.sosnoski.com/types"; count="11">
<result-set>
<area-name>Alaska - Aleutian Arc</area-name>
<regions count="1">
<region ident="rgn17" index="17">SOUTH OF ALASKA</region>
</regions>
<quakes count="1">
<quake depth="10.0" latitude="54.594"
longitude="-142.743" magnitude="5.2" method="MW" millis="2400"
region="rgn17" time="2001-05-14T07:22:13.000Z" />
</quakes>
Here's part of the corresponding schema from the WSDL:
<complexType name="Region">
<simpleContent>
<extension base="xsd:string">
<attribute name="ident" use="required" type="xsd:string"/>
<attribute name="index" use="required" type="xsd:int"/>
</extension>
</simpleContent>
</complexType>
<complexType name="Quake">
<attribute name="time" use="required" type="xsd:dateTime"/>
<attribute name="millis" use="required" type="xsd:int"/>
<attribute name="latitude" use="required" type="xsd:float"/>
<attribute name="longitude" use="required" type="xsd:float"/>
<attribute name="depth" use="required" type="xsd:float"/>
<attribute name="magnitude" use="required" type="xsd:float"/>
<attribute name="method" use="required" type="xsd:string"/>
<attribute name="region" use="required" type="xsd:string"/>
</complexType>
<complexType name="QuakeSet">
<sequence>
<element name="area-name" type="xsd:string"/>
<element name="regions">
<complexType>
<sequence>
<element name="region" minOccurs="0" maxOccurs="unbounded"
type="tns:Region"/>
</sequence>
<attribute name="count" use="required" type="xsd:int"/>
</complexType>
</element>
<element name="quakes">
<complexType>
<sequence>
<element name="quake" minOccurs="0" maxOccurs="unbounded"
type="tns:Quake"/>
</sequence>
<attribute name="count" use="required" type="xsd:int"/>
</complexType>
</element>
</sequence>
</complexType>
<element name="results">
<complexType>
<sequence>
<element name="result-set" minOccurs="0" maxOccurs="unbounded"
type="tns:QuakeSet"/>
</sequence>
<attribute name="count" use="required" type="xsd:int"/>
</complexType>
</element>
Though looking at your schema again, I see you're using
attributeFormDefault="qualified". This is generally not a good idea, and
because it's not widely used you may be running into some quirk as a
result. So try a capture to see what's going over the wire now, but then
try eliminating the attributeFormDefault and see what happens. If it
works with the attributeFormDefault removed please enter a Jira.
- Dennis
Dennis M. Sosnoski
SOA and Web Services in Java
Training and Consulting
http://www.sosnoski.com - http://www.sosnoski.co.nz
Seattle, WA +1-425-939-0576 - Wellington, NZ +64-4-298-6117
Chisholm, Paul wrote:
Dennis,
Thanks for that info. My invalid schema does indeed process without any
complaint from WSDL2Java.
I modified the schema as you suggested to
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";
attributeFormDefault="qualified"
elementFormDefault="qualified"
targetNamespace="http://quickstart.samples/xsd";>
<xs:element name="attribute">
<xs:complexType>
<xs:sequence>
<xs:element name="value" nillable="true" type="xs:string" />
</xs:sequence>
<xs:attribute name="status" type="xs:string" />
</xs:complexType>
</xs:element>
<xs:element name="attributeResponse">
<xs:complexType>
<xs:sequence>
<xs:element name="value" nillable="true" type="xs:string" />
</xs:sequence>
<xs:attribute name="status" type="xs:string" />
</xs:complexType>
</xs:element>
</xs:schema>
No luck unfortunately, the behaviour is exactly as before. The getter
for the XML attribute still returns null.
Paul
-----Original Message-----
From: Dennis Sosnoski [mailto:[EMAIL PROTECTED]
Sent: Thursday, 26 April 2007 10:43 AM
To: [email protected]
Subject: Re: XML attributes are null after transmission
Hi Paul,
Your complexType definitions are invalid, which may be the cause of the
problem. Attribute declarations need to be after the <sequence> element,
not before it. I'm surprised you're able to run WSDL2Java using this as
input without getting an error message - sounds like the schema model
needs some work on error checking.
- Dennis
Dennis M. Sosnoski
SOA and Web Services in Java
Training and Consulting
http://www.sosnoski.com - http://www.sosnoski.co.nz Seattle, WA
+1-425-939-0576 - Wellington, NZ +64-4-298-6117
Chisholm, Paul wrote:
Hi,
I am having a problem with data that is transferred via XML
attributes.
Namely, when an object is constructed after receiving a message the
getter corresponding to an attribute returns null.
I start with a WSDL file and use XMLBeans data binding. The following
example is a modification of the 'quickstartxmlbeans' sample supplied
with the software. I am using Axis2 1.1.1 and Java 1.6.0.
The schema in the wsdl:types section of the WSDL file is:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";
attributeFormDefault="qualified"
elementFormDefault="qualified"
targetNamespace="http://quickstart.samples/xsd";>
<xs:element name="attribute">
<xs:complexType>
<xs:attribute name="status" type="xs:string" />
<xs:sequence>
<xs:element name="value" nillable="true" type="xs:string" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="attributeResponse">
<xs:complexType>
<xs:attribute name="status" type="xs:string" />
<xs:sequence>
<xs:element name="value" nillable="true" type="xs:string" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
And the message/port definition is
<wsdl:message name="attributeMessage">
<wsdl:part name="part1" element="ns:attribute"/> </wsdl:message>
<wsdl:message name="attributeResponseMessage">
<wsdl:part name="part1" element="ns:attributeResponse"/>
</wsdl:message> <wsdl:portType name="MyServicePortType">
<wsdl:operation name="attribute">
<wsdl:input message="axis2:attributeMessage"/>
<wsdl:output message="axis2:attributeResponseMessage"/>
</wsdl:operation>
</wsdl:portType>
This defines a service whose request and response both contain an
attribute 'status' and an element 'value'.
The client sets the status attribute to "OK" and the value element to
"Testing" in the request. It calls the service and prints the status
attribute and value element that come back in the response.
public static void attribute(MyServiceStub stub){
try{
AttributeDocument reqDoc =
AttributeDocument.Factory.newInstance();
AttributeDocument.Attribute req =
reqDoc.addNewAttribute();
req.setStatus("OK");
req.setValue("Testing");
AttributeResponseDocument res = stub.attribute(reqDoc);
System.err.println("Status="+res.getAttributeResponse().getStatus());
System.err.println("Value="+res.getAttributeResponse().getValue());
} catch(Exception e){
e.printStackTrace();
System.err.println("\n\n\n");
}
}
The service just takes the status attrbiute and the value element from
the request and echos them back in the response.
public AttributeResponseDocument attribute(AttributeDocument
param1) {
String status = param1.getAttribute().getStatus();
String value = param1.getAttribute().getValue();
System.err.println();
System.err.println("Status="+status);
System.err.println("Value="+value);
AttributeResponseDocument resDoc =
AttributeResponseDocument.Factory.newInstance();
AttributeResponseDocument.AttributeResponse res =
resDoc.addNewAttributeResponse();
res.setStatus(status);
res.setValue(value);
return resDoc;
}
When I run the client I get the following output:
run.client:
[java] Status=null
[java] Value=Testing
The value element is correct, but the status attribute is null. A
trace on the server side shows the same problem. That is, after the
request is received on the server the status attribute is null.
I changed the status attribute to a status element and all was
processed fine, so the problem seems to be specific to XML attributes.
Is something extra needed when XML attributes are involved?
Thanks,
Paul Chisholm
Technology Support/TAS
Airservices Australia
www.airservicesaustralia.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CAUTION: This e-mail is confidential. If you are not the intended
recipient, you must not disclose or use the information contained in
it. If you have received this e-mail in error, please tell us
immediately by return e-mail and delete the document.
Airservices Australia does not represent, warrant or guarantee that
the integrity of this communication is free of errors, virus or
interference.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
