axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chuck Williams (JIRA)" <>
Subject [jira] Commented: (AXIS2-632) get errors trying to parse valid response
Date Sat, 29 Apr 2006 00:06:37 GMT
    [ ] 

Chuck Williams commented on AXIS2-632:

The issue here is that the wsdl defines the <records> element to be an sObject:

            <complexType name="QueryResult">
                    <element name="done"         type="xsd:boolean"/>
                    <element name="queryLocator" type="tns:QueryLocator" nillable="true"/>
                    <element name="records"      type="ens:sObject" nillable="true" minOccurs="0"
                    <element name="size"         type="xsd:int"/>

and then the message specifies the type to be an sAccount:

    <records xsi:type="sf:Account">
        <sf:Name>New Account 2</sf:Name>

while sObject does not have the AccountNumber or Name property:

            <complexType name="sObject">


                    <element name="fieldsToNull"       type="xsd:string" nillable="true"
minOccurs="0" maxOccurs="unbounded"/>

                    <element name="Id"                 type="tns:ID" nillable="true" minOccurs="0"
maxOccurs="1" />



and Account adds them as an extension type:

            <complexType name="Account">
                    <extension base="ens:sObject">
                        <element name="AccountNumber" nillable="true" minOccurs="0" type="xsd:string"/>
                        <element name="Name" nillable="true" minOccurs="0" type="xsd:string"/>

But the generated code is based solely on the declaration of QueryResult and so parses the
<records> element as an sObject.  sObject does not allow the extra properties.  Whence,
the exception.

The bottom line is that the current code generator does not support this construction with
extension types.  Unless this is a required feature for 1.0, I'd say this is not a bug.

It could be considered a bug that the error message is not:  "Unexpected subelement AccountNumber".
 The cause of this could lead to some improper behavior in other cases, but never with properly
formatted xml.  It's just an error recovery/reporting issue.

In looking at this I saw another anomaly that should be corrected.  If you take the xml of
this example and format it for easy reading, and then try to parse it, you get an infinite
loop!!  This is not good.  There is one place in the template (at least) where an invalid
assumption is made that should be fixed.  It could lead to proper xml not being parsed correctly
if it is formatted with extra ignorable whitespace.  I'm looking at that now.

> get errors trying to parse valid response
> -----------------------------------------
>          Key: AXIS2-632
>          URL:
>      Project: Apache Axis 2.0 (Axis2)
>         Type: Bug

>   Components: databinding
>  Environment: Axis2.0 RC4, JDK 1.5.06, WinXP
>     Reporter: Simon Fell
>     Priority: Blocker

> A valid response from the query call (wsdl is the enterprise wsdl that's now part of
the tests) fails to be de-serialized with an error.
> Exception in thread "main" java.lang.RuntimeException: java.lang.RuntimeException: Unexpected
subelement Name
> 	at org.apache.axis2.SforceServiceStub.fromOM(
> 	at org.apache.axis2.SforceServiceStub.query(
> 	at client.main(
> Caused by: java.lang.RuntimeException: Unexpected subelement Name
> 	at org.apache.axis2.SforceServiceStub$QueryResult$Factory.parse(
> 	at org.apache.axis2.SforceServiceStub$QueryResponse$Factory.parse(
> 	at org.apache.axis2.SforceServiceStub.fromOM(
> 	... 2 more
> Here's the response msg it fails to deserialize
> <?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:soapenv=""
xmlns:xsd="" xmlns:xsi=""
xmlns="" xmlns:sf=""><soapenv:Body><queryResponse><result><done>true</done><queryLocator
xsi:nil="true"/><records xsi:type="sf:Account"><sf:Id>0013000000Bnr1qAAB</sf:Id><sf:AccountNumber>axis2Test</sf:AccountNumber><sf:Name>New
Account 2</sf:Name></records><records xsi:type="sf:Account"><sf:Id>0013000000BnspUAAR</sf:Id><sf:AccountNumber>axis2Test</sf:AccountNumber><sf:Name>New
Account 1</sf:Name></records><size>2</size></result></queryResponse></soapenv:Body></soapenv:Envelope>
> the client stub was generated with WSDL2Java -s -u -uri enterprise.wsdl
> The test code is
> 		SforceServiceStub stub = new SforceServiceStub();
> 		SforceServiceStub.Login l = new SforceServiceStub.Login();
> 		l.setUsername("*username*");
> 		l.setPassword("*password*");
> 		SforceServiceStub.LoginResponse lr = stub.login(l);
> 		SforceServiceStub.SessionHeader sh = new SforceServiceStub.SessionHeader();
> 		sh.setSessionId(lr.getResult().getSessionId());
> 		stub = new SforceServiceStub(lr.getResult().getServerUrl());
> 		SforceServiceStub.Query q = new SforceServiceStub.Query();
> 		q.setQueryString("select id, name, AccountNumber from Account where AccountNumber='axis2Test'");
> 		SforceServiceStub.QueryResponse qr = stub.query(q, sh, null);
> 		System.out.println("query returned " + qr.getResult().getSize() + " rows");
> 		for(SforceServiceStub.SObject o : qr.getResult().getRecords()) {
> 			SforceServiceStub.Account a = (SforceServiceStub.Account)o;
> 			System.out.println(a.getId() + " " + a.getName() + " " + a.getAccountNumber());
> 		}
> Also the generated stub has getId() returning an OMElement, and not a string.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message