You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by Joel Carklin <jo...@ipay.co.za> on 2005/07/25 14:02:09 UTC

Advice regarding incorrect handling of xsd:choice

Hi,

I'm sure others on this list have come across this same problem, since
I've found other descriptions of the same problem in the archives.

I haven't really found any suggestions for working around it though.
 
I'm pretty sure it's a bug, based on a brief search through jira,
which came up with the following (among many others) which seem to
apply:
http://issues.apache.org/jira/browse/AXIS-1849
http://issues.apache.org/jira/browse/AXIS-1437
http://issues.apache.org/jira/browse/AXIS-1802

Basically, the following in the wsdl: 

<element name="Request">
  <complexType>
    <sequence>
      <choice minOccurs="1" maxOccurs="1"> 
        <element minOccurs="0" maxOccurs="1" name="One" type="i0:ONET"/>
        <element minOccurs="0" maxOccurs="1" name="Two" type="i0:TWOT"/>
        <element minOccurs="0" maxOccurs="1" name="Thr" type="i0:THRT"/>
      </choice>
    </sequence>
  </complexType>
</element>

generates the following xml, which is sent to the web service:

<One>0nly This one should exist</One>
<Two xsi:nil="true"/>
<Thr xsi:nil="true"/>

The elements where xsi:nil="true" should be left out completely, with
only the non-null element being sent.

Can anybody suggest a way to work around this?
If I want to hack the Axis code to make it do what I want (last resort),
where should I be looking? Or perhaps I should use something else like
wscompile, or Castor to generate the classes?  

Any suggestions/advice appreciated!

Thanks
Joel

Re: the response is strange (6 small squares in the TCPmonitor)

Posted by Chris Kelly <ab...@tolstoy.com>.
On 25 Jul 2005 at 17:04, Thibaut Lassalle wrote:
> i use a .net webservice and i have to write a axis webservice client.
> The url of the webservice is https.
> I generate a stub from the WSDL file.
> The request xml is ok (verify with TCPmonitor) but the response is 
> strange (6 small squares in the TCPmonitor, no xml).

Perhaps you're getting binary back, and that data would give a clue. In the version of 
com.apache.axis.utils.tcpmon.java that I have, SocketRR.run() seems to be where 
the text is printed to the JTextArea. As a start I'd modify that to show binary as ASCII 
or similar.

-- 
http://jerimoth.com/ Free tech job posting and search service.

Re: Advice regarding incorrect handling of xsd:choice

Posted by Davanum Srinivas <da...@gmail.com>.
confirm...nowrapped=true should be ok. 

-- dins

On 7/26/05, Joel Carklin <jo...@ipay.co.za> wrote:
> Well, amazingly enough I accidentally discovered something which solved
> my problem. I'm surprised it hasn't been mentioned here before, but
> maybe it's peculiar to my specific wsdl.
> 
> In order to clean up my code a bit, I regenerated my classes using
> wsdl2java, but this time I used the ant task param: nowrapped=true (the
> -W command line option). I don't really understand the wrapped concept,
> though I'm reading up on it now. All I know is that when using the
> nowrapped=true option, my stubs methods accept objects which encapsulate
> the parameters needed by the method, whereas without it, the methods
> needs each parameter separately.
> 
> And I discovered, the XML produced with the new stub doesn't have the
> problem outlined below. All null elements are left out completely, which
> is exactly what I wanted!
> 
> The only thing now is I'm a little worried using the nowrapped=true
> might have disadvantages I'm not aware of? If so let me know!
> 
> Anne, I didn't want to change the element definitions if I could help
> it, since I'm using a wsdl from an external source...
> 
> 
> On Tue, 2005-07-26 at 00:52, Anne Thomas Manes wrote:
> > wscompile won't work. The Sun JAX-RPC reference implementation doesn't
> > support <choice>.
> >
> > I believe Castor also has trouble with <choice> (see
> > http://archive.codehaus.org/castor/user/msg00814.html).
> >
> > What happens if you add nillable="false" to the element definitions?
> >
> > Anne
> >
> > On 7/25/05, Joel Carklin <jo...@ipay.co.za> wrote:
> > > Hi,
> > >
> > > I'm sure others on this list have come across this same problem, since
> > > I've found other descriptions of the same problem in the archives.
> > >
> > > I haven't really found any suggestions for working around it though.
> > >
> > > I'm pretty sure it's a bug, based on a brief search through jira,
> > > which came up with the following (among many others) which seem to
> > > apply:
> > > http://issues.apache.org/jira/browse/AXIS-1849
> > > http://issues.apache.org/jira/browse/AXIS-1437
> > > http://issues.apache.org/jira/browse/AXIS-1802
> > >
> > > Basically, the following in the wsdl:
> > >
> > > <element name="Request">
> > >   <complexType>
> > >     <sequence>
> > >       <choice minOccurs="1" maxOccurs="1">
> > >         <element minOccurs="0" maxOccurs="1" name="One" type="i0:ONET"/>
> > >         <element minOccurs="0" maxOccurs="1" name="Two" type="i0:TWOT"/>
> > >         <element minOccurs="0" maxOccurs="1" name="Thr" type="i0:THRT"/>
> > >       </choice>
> > >     </sequence>
> > >   </complexType>
> > > </element>
> > >
> > > generates the following xml, which is sent to the web service:
> > >
> > > <One>0nly This one should exist</One>
> > > <Two xsi:nil="true"/>
> > > <Thr xsi:nil="true"/>
> > >
> > > The elements where xsi:nil="true" should be left out completely, with
> > > only the non-null element being sent.
> > >
> > > Can anybody suggest a way to work around this?
> > > If I want to hack the Axis code to make it do what I want (last resort),
> > > where should I be looking? Or perhaps I should use something else like
> > > wscompile, or Castor to generate the classes?
> > >
> > > Any suggestions/advice appreciated!
> > >
> > > Thanks
> > > Joel
> > >
> > >
> 
> 


-- 
Davanum Srinivas -http://blogs.cocoondev.org/dims/

Re: Advice regarding incorrect handling of xsd:choice

Posted by Joel Carklin <jo...@ipay.co.za>.
Well, amazingly enough I accidentally discovered something which solved
my problem. I'm surprised it hasn't been mentioned here before, but
maybe it's peculiar to my specific wsdl.

In order to clean up my code a bit, I regenerated my classes using
wsdl2java, but this time I used the ant task param: nowrapped=true (the
-W command line option). I don't really understand the wrapped concept,
though I'm reading up on it now. All I know is that when using the
nowrapped=true option, my stubs methods accept objects which encapsulate
the parameters needed by the method, whereas without it, the methods
needs each parameter separately.
 
And I discovered, the XML produced with the new stub doesn't have the
problem outlined below. All null elements are left out completely, which
is exactly what I wanted!

The only thing now is I'm a little worried using the nowrapped=true
might have disadvantages I'm not aware of? If so let me know!

Anne, I didn't want to change the element definitions if I could help
it, since I'm using a wsdl from an external source...   
 

On Tue, 2005-07-26 at 00:52, Anne Thomas Manes wrote:
> wscompile won't work. The Sun JAX-RPC reference implementation doesn't
> support <choice>.
> 
> I believe Castor also has trouble with <choice> (see
> http://archive.codehaus.org/castor/user/msg00814.html).
> 
> What happens if you add nillable="false" to the element definitions?
> 
> Anne
> 
> On 7/25/05, Joel Carklin <jo...@ipay.co.za> wrote:
> > Hi,
> > 
> > I'm sure others on this list have come across this same problem, since
> > I've found other descriptions of the same problem in the archives.
> > 
> > I haven't really found any suggestions for working around it though.
> > 
> > I'm pretty sure it's a bug, based on a brief search through jira,
> > which came up with the following (among many others) which seem to
> > apply:
> > http://issues.apache.org/jira/browse/AXIS-1849
> > http://issues.apache.org/jira/browse/AXIS-1437
> > http://issues.apache.org/jira/browse/AXIS-1802
> > 
> > Basically, the following in the wsdl:
> > 
> > <element name="Request">
> >   <complexType>
> >     <sequence>
> >       <choice minOccurs="1" maxOccurs="1">
> >         <element minOccurs="0" maxOccurs="1" name="One" type="i0:ONET"/>
> >         <element minOccurs="0" maxOccurs="1" name="Two" type="i0:TWOT"/>
> >         <element minOccurs="0" maxOccurs="1" name="Thr" type="i0:THRT"/>
> >       </choice>
> >     </sequence>
> >   </complexType>
> > </element>
> > 
> > generates the following xml, which is sent to the web service:
> > 
> > <One>0nly This one should exist</One>
> > <Two xsi:nil="true"/>
> > <Thr xsi:nil="true"/>
> > 
> > The elements where xsi:nil="true" should be left out completely, with
> > only the non-null element being sent.
> > 
> > Can anybody suggest a way to work around this?
> > If I want to hack the Axis code to make it do what I want (last resort),
> > where should I be looking? Or perhaps I should use something else like
> > wscompile, or Castor to generate the classes?
> > 
> > Any suggestions/advice appreciated!
> > 
> > Thanks
> > Joel
> > 
> >

Re: Advice regarding incorrect handling of xsd:choice

Posted by Anne Thomas Manes <at...@gmail.com>.
wscompile won't work. The Sun JAX-RPC reference implementation doesn't
support <choice>.

I believe Castor also has trouble with <choice> (see
http://archive.codehaus.org/castor/user/msg00814.html).

What happens if you add nillable="false" to the element definitions?

Anne

On 7/25/05, Joel Carklin <jo...@ipay.co.za> wrote:
> Hi,
> 
> I'm sure others on this list have come across this same problem, since
> I've found other descriptions of the same problem in the archives.
> 
> I haven't really found any suggestions for working around it though.
> 
> I'm pretty sure it's a bug, based on a brief search through jira,
> which came up with the following (among many others) which seem to
> apply:
> http://issues.apache.org/jira/browse/AXIS-1849
> http://issues.apache.org/jira/browse/AXIS-1437
> http://issues.apache.org/jira/browse/AXIS-1802
> 
> Basically, the following in the wsdl:
> 
> <element name="Request">
>   <complexType>
>     <sequence>
>       <choice minOccurs="1" maxOccurs="1">
>         <element minOccurs="0" maxOccurs="1" name="One" type="i0:ONET"/>
>         <element minOccurs="0" maxOccurs="1" name="Two" type="i0:TWOT"/>
>         <element minOccurs="0" maxOccurs="1" name="Thr" type="i0:THRT"/>
>       </choice>
>     </sequence>
>   </complexType>
> </element>
> 
> generates the following xml, which is sent to the web service:
> 
> <One>0nly This one should exist</One>
> <Two xsi:nil="true"/>
> <Thr xsi:nil="true"/>
> 
> The elements where xsi:nil="true" should be left out completely, with
> only the non-null element being sent.
> 
> Can anybody suggest a way to work around this?
> If I want to hack the Axis code to make it do what I want (last resort),
> where should I be looking? Or perhaps I should use something else like
> wscompile, or Castor to generate the classes?
> 
> Any suggestions/advice appreciated!
> 
> Thanks
> Joel
> 
>

the response is strange (6 small squares in the TCPmonitor)

Posted by Thibaut Lassalle <tl...@cvdunet.com>.
hi,

i use a .net webservice and i have to write a axis webservice client.
The url of the webservice is https.
I generate a stub from the WSDL file.
The request xml is ok (verify with TCPmonitor) but the response is 
strange (6 small squares in the TCPmonitor, no xml).

Any idea ?



The java exception (on the client side) is :



Exception in thread "main" AxisFault
 faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException
 faultSubcode:
 faultString: java.lang.NullPointerException
 faultActor:
 faultNode:
 faultDetail:
    {http://xml.apache.org/axis/}stackTrace:java.lang.NullPointerException
    at org.xml.sax.helpers.AttributesImpl.getValue(AttributesImpl.java:286)
    at 
org.apache.axis.message.MessageElement.&lt;init&gt;(MessageElement.java:263)
    at 
org.apache.axis.message.SOAPHandler.makeNewElement(SOAPHandler.java:103)
    at org.apache.axis.message.SOAPHandler.startElement(SOAPHandler.java:88)
    at 
org.apache.axis.encoding.DeserializationContext.startElement(DeserializationContext.java:1048)
    at 
org.apache.xerces.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:342)
    at 
org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(AbstractXMLDocumentParser.java:209)
    at 
org.apache.xerces.impl.xs.XMLSchemaValidator.emptyElement(XMLSchemaValidator.java:420)
    at 
org.apache.xerces.impl.XMLNamespaceBinder.handleStartElement(XMLNamespaceBinder.java:806)
    at 
org.apache.xerces.impl.XMLNamespaceBinder.emptyElement(XMLNamespaceBinder.java:576)
    at 
org.apache.xerces.impl.dtd.XMLDTDValidator.handleStartElement(XMLDTDValidator.java:2675)
    at 
org.apache.xerces.impl.dtd.XMLDTDValidator.emptyElement(XMLDTDValidator.java:797)
    at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(XMLDocumentFragmentScannerImpl.java:743)
    at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1445)
    at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:328)
    at 
org.apache.xerces.parsers.StandardParserConfiguration.parse(StandardParserConfiguration.java:479)
    at 
org.apache.xerces.parsers.StandardParserConfiguration.parse(StandardParserConfiguration.java:521)
    at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:148)
    at 
org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:972)
    at javax.xml.parsers.SAXParser.parse(SAXParser.java:345)
    at 
org.apache.axis.encoding.DeserializationContext.parse(DeserializationContext.java:227)
    at org.apache.axis.SOAPPart.getAsSOAPEnvelope(SOAPPart.java:696)
    at org.apache.axis.Message.getSOAPEnvelope(Message.java:424)
    at 
org.apache.axis.handlers.soap.MustUnderstandChecker.invoke(MustUnderstandChecker.java:62)
    at org.apache.axis.client.AxisClient.invoke(AxisClient.java:206)
    at org.apache.axis.client.Call.invokeEngine(Call.java:2765)
    at org.apache.axis.client.Call.invoke(Call.java:2748)
    at org.apache.axis.client.Call.invoke(Call.java:2424)
    at org.apache.axis.client.Call.invoke(Call.java:2347)
    at org.apache.axis.client.Call.invoke(Call.java:1804)
    at 
com.monster.www.definitions.BusinessGatewayImplStub.executeQuery(BusinessGatewayImplStub.java:3141)
    at com.cvdunet.webservice.GetJobInfo.main(GetJobInfo.java:87)

    {http://xml.apache.org/axis/}hostname:localhost

java.lang.NullPointerException
    at org.apache.axis.AxisFault.makeFault(AxisFault.java:101)
    at org.apache.axis.SOAPPart.getAsSOAPEnvelope(SOAPPart.java:701)
    at org.apache.axis.Message.getSOAPEnvelope(Message.java:424)
    at 
org.apache.axis.handlers.soap.MustUnderstandChecker.invoke(MustUnderstandChecker.java:62)
    at org.apache.axis.client.AxisClient.invoke(AxisClient.java:206)
    at org.apache.axis.client.Call.invokeEngine(Call.java:2765)
    at org.apache.axis.client.Call.invoke(Call.java:2748)
    at org.apache.axis.client.Call.invoke(Call.java:2424)
    at org.apache.axis.client.Call.invoke(Call.java:2347)
    at org.apache.axis.client.Call.invoke(Call.java:1804)
    at 
com.monster.www.definitions.BusinessGatewayImplStub.executeQuery(BusinessGatewayImplStub.java:3141)
    at com.cvdunet.webservice.GetJobInfo.main(GetJobInfo.java:87)
Caused by: java.lang.NullPointerException
    at org.xml.sax.helpers.AttributesImpl.getValue(AttributesImpl.java:286)
    at 
org.apache.axis.message.MessageElement.<init>(MessageElement.java:263)
    at 
org.apache.axis.message.SOAPHandler.makeNewElement(SOAPHandler.java:103)
    at org.apache.axis.message.SOAPHandler.startElement(SOAPHandler.java:88)
    at 
org.apache.axis.encoding.DeserializationContext.startElement(DeserializationContext.java:1048)
    at 
org.apache.xerces.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:342)
    at 
org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(AbstractXMLDocumentParser.java:209)
    at 
org.apache.xerces.impl.xs.XMLSchemaValidator.emptyElement(XMLSchemaValidator.java:420)
    at 
org.apache.xerces.impl.XMLNamespaceBinder.handleStartElement(XMLNamespaceBinder.java:806)
    at 
org.apache.xerces.impl.XMLNamespaceBinder.emptyElement(XMLNamespaceBinder.java:576)
    at 
org.apache.xerces.impl.dtd.XMLDTDValidator.handleStartElement(XMLDTDValidator.java:2675)
    at 
org.apache.xerces.impl.dtd.XMLDTDValidator.emptyElement(XMLDTDValidator.java:797)
    at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(XMLDocumentFragmentScannerImpl.java:743)
    at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1445)
    at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:328)
    at 
org.apache.xerces.parsers.StandardParserConfiguration.parse(StandardParserConfiguration.java:479)
    at 
org.apache.xerces.parsers.StandardParserConfiguration.parse(StandardParserConfiguration.java:521)
    at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:148)
    at 
org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:972)
    at javax.xml.parsers.SAXParser.parse(SAXParser.java:345)
    at 
org.apache.axis.encoding.DeserializationContext.parse(DeserializationContext.java:227)
    at org.apache.axis.SOAPPart.getAsSOAPEnvelope(SOAPPart.java:696)
    ... 10 more