Hi Dushshantha, Samisa,
I am running the FaultMappingDoc test against WebSphere Application Server
and I want to make the Axis C++ client interoperable with both the Axis C++
server and WebSphere Application Server.

I notice that the code in SoapFault::serialize that always put a
<appSpecific> element inside a <detail> element has now been removed. So
for complex faults, the Axis C++ server isn't wrapping the fault in a
<appSpecific> element. So this means I should be ok to remove the code in
SoapDeSerializer::getElement that steps over the <appSpecific>.

Please let me know if this is ok and I will make the change tomorrow,
Thanks,
Mark
Mark Whitlock
IBM

----- Forwarded by Mark Whitlock/UK/IBM on 18/08/2005 11:17 -----
                                                                           
             "Samisa                                                       
             Abeysinghe"                                                   
             <[EMAIL PROTECTED]                                          To 
             usa.com>                  "Henrik Nordberg"                   
                                       <[EMAIL PROTECTED]>           
             18/08/2005 06:04                                           cc 
                                       <[email protected]>          
                                                                   Subject 
             Please respond to         RE: Dushshantha: FaultMappingDoc    
              "Apache AXIS C           broken                              
             Developers List"                                              
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Thanks for the information.

Samisa...

> -----Original Message-----
> From: Henrik Nordberg [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 18, 2005 10:48 AM
> To: Samisa Abeysinghe
> Cc: Dushshantha Chandradasa
> Subject: Re: Dushshantha: FaultMappingDoc broken
>
> Yes, the current implementation with <appSpecific> nested in <detail>
is
> correct. See http://issues.apache.org/jira/browse/AXIS-1836 for a
> discussion
> on this.
>
> I am sending to you directly because I am having email trouble at home
> (can't send from the email I am subscribed to the list with).
>
>  - Henrik
>
> ----- Original Message -----
> From: "Samisa Abeysinghe" <[EMAIL PROTECTED]>
> To: "Apache AXIS C Developers List" <[email protected]>
> Sent: Wednesday, August 17, 2005 9:11 PM
> Subject: RE: Dushshantha: FaultMappingDoc broken
>
>
> Hi Dushshantha,
> Is your SOAP fault response format compatible with the SOAP
> spec?
> Thanks,
> Samisa...
>
> > -----Original Message-----
> > From: Dushshantha Chandradasa [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, August 18, 2005 9:52 AM
> > To: Apache AXIS C Developers List
> > Subject: RE: Dushshantha: FaultMappingDoc broken
> >
> > Hi Mark,
> > I think I got your problem. I made these changes on deserializer to
> > correctly deserialize both complex and simple faults. For me, the
> detail
> > tag of the server response message is somewhat deferent. It looks
like
> > ..
> >
> > <SOAP-ENV:Fault>
> > <faultcode>AxisC++ Faultcode</faultcode>
> > <faultstring>Custom Out of bound exception</faultstring>
> > <faultactor>server name:listen port</faultactor>
> > <detail><appSpecific><DivByZeroStruct><ns1:varString>Division by
zero
> > exception</ns1:varString>
> > <ns1:varInt>1</ns1:varInt>
> > <ns1:varFloat>10.520000</ns1:varFloat>
> > </DivByZeroStruct>
> > </appSpecific></detail>
> > </SOAP-ENV:Fault>
> >
> > It includes an additional <appSpecific> tag in the message. This was
> > introduced as a fix to the issue AXISCPP-706.
> >
> > I think you are using MockServer and your server response file does
> not
> > contain this <appSpecific> tag.
> >
> > Please refer to http://issues.apache.org/jira/browse/AXISCPP-723 to
> > understand my changes. Sorry for the inconvenience.
> >
> > Regards,
> > Dushshantha
> >
> > -----Original Message-----
> > From: Mark Whitlock [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, August 17, 2005 9:43 PM
> > To: [email protected]
> > Subject: Dushshantha: FaultMappingDoc broken
> >
> >
> >
> >
> >
> > Hi Dushshantha,
> > I am investigating the FaultMappingDoc test which is currently
failing
> > for
> > us. It started failing on 26/07/05 (apologies that it has taken me
so
> > long
> > to catch up with this problem). I believe the change that broke it
was
> > 1.172 of SoapDeSerializer.cpp. Revision 1.174 of
SoapDeSerializer.cpp
> > altered that fix to add in these lines into
> SoapDeSerializer::getElement
> > in
> > the doc-literal clause...
> >
> > if (0 == strcmp(pName,"detail") )
> > {
> >   m_pNode = m_pParser->next ();
> > }
> >
> > When I comment out these lines FaultMappingDoc passes. When the
> service
> > returns a DivByZeroStruct soap fault, the FaultMappingDocClient is
> > expecting to catch a DivByZeroStruct, but instead it catches a
> > SoapFaultException. The generated MathOps stub decides which fault
to
> > throw
> > by calling SoapFault::getCmplxFaultObjectName which (from the trace)
> > should
> > return "DivByZeroStruct" but instead returns "varString". The
relevant
> > part
> > of the response message is...
> >
> > <soapenv:Fault>
> > <faultcode xmlns:ns2008922717="http://soapinterop.org/wsdl";
> > xmlns="">ns2008922717:DivByZeroStruct</faultcode>
> > <faultstring xmlns="">org.soapinterop.DivByZeroStruct</faultstring>
> > <detail xmlns="">
> > <DivByZeroStruct xmlns="http://soapinterop.org/wsdl";>
> > <varString>Division by zero exception</varString>
> > <varInt>1</varInt>
> > <varFloat>10.52</varFloat>
> > </DivByZeroStruct>
> > </detail>
> > </soapenv:Fault>
> >
> > So it looks like the SoapDeSerializer is stepping over one too many
> > tags.
> > FaultMappingRepeatedDoc and OtherFaultException also fail in the
same
> > way.
> > I guess the same problem may happen for rpc-encoded.
> >
> > I don't understand what you were fixing so I don't like to back out
> your
> > change. Please could you help me to fix this?
> > Thanks,
> > Mark
> > Mark Whitlock
> >
>
>
>


Reply via email to