Hi, Ok, I can't see anything obviously wrong with your SOAP message ... I wouldn't expect the & to cause problems, as we have a passing testcase to check the correct encoding/decoding of this, and looking through the SVN history the code which handles encoding/decoding hasn't been touched since before the release of 1.5.
I'm wondering if perhaps you're hitting a problem with the transport/parser interaction. I should have asked before, can you also include the HTTP headers, etc. so I can check if there are any content/chunk length issues here. Regards, Adrian _______________________________________ Adrian Dick ([EMAIL PROTECTED]) "Iwan Tomlow" <[EMAIL PROTECTED]> wrote on 16/05/2006 10:01:03: > Sure, this is the on-the-wire message (in which I had to replace some > personal data for confidentiality). > The & in <employerName> causes XercesHandler to parse the data in 2 > steps, and the 2nd call to XercesHandler::characters is causing problems > in the use of 'cp_PreviousNameOrValue'. > > Thanks for your assistance, > Iwan > > <?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> > <getCardResponse xmlns="http://thenamespace"> > <getCardReturn> > <cardNumber>12345</cardNumber> > <cardState>104</cardState> > <cardValidTo>03/11/2008</cardValidTo> > <cardVersion>0</cardVersion> > <customerCode>0</customerCode> > <dateOfBirth>01/01/1975</dateOfBirth> > <employerCity>SOMEWHERE</employerCity> > <employerCountry>XX</employerCountry><employerName>BOOT & > BUTEIJN</employerName> > <employerNumber>1234</employerNumber><employerPhone>0000/999.999.999</em > ployerPhone> > <employerStreet>THERE</employerStreet> > <employerZip>9999AA</employerZip> > <firstName>FIRST</firstName> > <groupNumber>1</groupNumber> > <homeAddressCity>CITY</homeAddressCity> > <homeAddressCountry>XX</homeAddressCountry> > <homeAddressStreet>STREET 11</homeAddressStreet> > <homeAddressZip>9999AA</homeAddressZip> > <homePhone xsi:nil="true"/> > <lastName>LAST</lastName> > <nationality>XX</nationality> > <personnelNumber>9999</personnelNumber> > <qualification1 xsi:nil="true"/><qualification2 > xsi:nil="true"/><qualification3 xsi:nil="true"/><subgroupNumber > xsi:nil="true"/> > </getCardReturn> > </getCardResponse> > </soapenv:Body> > </soapenv:Envelope> > > -----Original Message----- > From: Adrian Dick [mailto:[EMAIL PROTECTED] > Sent: dinsdag 16 mei 2006 10:21 > To: Apache AXIS C User List > Subject: RE: Crash in XercesHandler.cpp with & in response > > Hi, > > As we've now excluded the illegal use of '&', it could be related to how > the SOAP message is being received, I know of some bugs fixed in 1.6 > which could cause similar problems to those you describe. > Is it possible for you to attach the "on-the-wire" SOAP/HTTP message > causing this problem? > > Thanks, > Adrian > _______________________________________ > Adrian Dick ([EMAIL PROTECTED]) > > > "Iwan Tomlow" <[EMAIL PROTECTED]> wrote on 15/05/2006 16:41:16: > > > Hm, sorry I didn't make this clear enough: when looking at the data > > over the wire, the ampersand is escaped correctly. > > The webservice is deployed with axis-java, so no problems there. My > > example should read <name>BOOT & BUTEIJN</name>. > > The & was already resolved by xerces when I copy/pasted the value > > to this e-mail, sorry for the confusion. > > > > So Xerces parser has no problems at all, but there seems to be a bug > > in the XercesHandler implementation in Axis. > > Btw, I have the problem with both Xerces 2.2.0 (as included in axis > > 1.5 release), and also when I build Axis 1.5 myself linked with Xerces > > > 2.7.0. > > > > I have not been able to use the 1.6 nightly build yet, and I would > > rather be able to quickly fix the production problem with a 1.5 patch > > first. > > > > Regards, > > Iwan > > > > -----Original Message----- > > From: Adrian Dick [mailto:[EMAIL PROTECTED] > > Sent: maandag 15 mei 2006 17:20 > > To: Apache AXIS C User List > > Subject: Re: Crash in XercesHandler.cpp with & in response > > > > Hi, > > > > > > Under the SOAP (and underlying XML) standards the ampersand character > > is reserved, so you are not permitted to use it within data. > > You will need to ensure any occurances are correctly encoded --- ie: > > '&' > > becomes "&". > > > > It looks quite likely the Xerces Parser is failing when it hits this > > invalid use of '&'. > > > > How is this XML data being produced? Are you using xsd:any -- in > which > > case you'll need to ensure this encoding takes place -- or are you > > seeing an error in the Axis serialization code, where this should be > > taking place on your behalf. > > > > Are you in a position to test if this problem is still present with > > the latest Axis 1.6 nightly builds? > > > > Regards, > > Adrian > > _______________________________________ > > Adrian Dick ([EMAIL PROTECTED]) > > > > > > "Iwan Tomlow" <[EMAIL PROTECTED]> wrote on 15/05/2006 13:34:04: > > > > > Hi all, > > > > > > I'm using the Axis C++ 1.5 in a production project, and we are > > > experiencing problems when the response from the webservice contains > > > > ampersands in the xml-data, like <name>BOOT & BUTEIJN</name>. > > > > > > The generated Axis-client stub crashes (with 'Invalid Address > > > specified to RtlFreeHeap' in MCVC6.0 debugger) on the following code > > > > in XercesHandler::characters > > > >>> free(const_cast <char*> (cp_PreviousNameOrValue)); > > > free(cp_CurrentNameOrValue); > > > > > > I found a jira-issue (AXISCPP-825) that seems to address this issue, > > > > but the reported fix (change free to delete[]) does not work for me, > > > > the result is the same. > > > > > > Does anyone have this issue, any hints? > > > Strange thing: it appears everything works fine if a point my > > > XMLParser in axiscpp.conf to the debug-library 'AxisXMLParser_D.dll' > > > instead of the release-build, but I'm afraid that is just a > > coincidence. > > > > > > Any help appreciated. > > > > > > Kind regards, > > > Iwan Tomlow > > >
