[ http://issues.apache.org/jira/browse/AXIS2-928?page=comments#action_12423454 ] Derek Foster commented on AXIS2-928: ------------------------------------
The version I was running when I reported this was the nightly build from about four days ago. I just downloaded and tested the latest nightly build, and verified that the bug still exists. > Not all added header elements are included in outgoing SOAP header unless run > under debugger - bug in OMElement caching? > ------------------------------------------------------------------------------------------------------------------------ > > Key: AXIS2-928 > URL: http://issues.apache.org/jira/browse/AXIS2-928 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Bug > Components: client-api > Affects Versions: 1.0 > Reporter: Derek Foster > Priority: Critical > > Hi, folks. > I have two custom headers, CARSLogin and CARSPassword, that are declared and > used in my WSDL like so: > <types> > <xs:schema targetNamespace="http://www.c-corp.com/wsdl/2004-10-01/f";> > <xs:import namespace="http://www.dummy-temp-address"; > schemaLocation="F.xsd"/> > <xs:element name="return" type="xs:string"/> > <xs:element name="failure" type="xs:string"/> > </xs:schema> > <xs:schema targetNamespace="http://www.c-corp.com/wsdl/2004-10-01/C";> > <xs:element name="CPassword" type="xs:string"/> > <xs:element name="CLogin" type="xs:string"/> > </xs:schema> > </types> > <message name="FEvent"> > <part name="contents" element="f:full-event-update"/> > </message> > <message name="FResponse"> > <part name="return" element="tns:return"/> > </message> > <message name="CPassword"> > <part name="CPassword" element="C:CPassword"/> > </message> > <message name="CLogin"> > <part name="CLogin" element="C:CLogin"/> > </message> > <message name="Failure"> > <part name="faultDetail" element="tns:failure"/> > </message> > <portType name="FPortType"> > <documentation>F Port Type</documentation> > <operation name="acceptFEvent" parameterOrder="contents"> > <input name="acceptFEventRequest" message="tns:FEvent"/> > <output name="acceptFEventResponse" message="tns:FResponse"/> > <fault name="Failure" message="tns:Failure"/> > </operation> > </portType> > <binding name="FSoapBinding" type="tns:FPortType"> > <documentation>F Soap Binding</documentation> > <soap:binding style="document" > transport="http://schemas.xmlsoap.org/soap/http"/> > <operation name="acceptFEvent"> > <soap:operation soapAction="acceptFEventAction"/> > <input> > <soap:header message="tns:CLogin" part="CLogin" use="literal"/> > <soap:header message="tns:CPassword" part="CPassword" > use="literal"/> > <soap:body use="literal"/> > </input> > <output> > <soap:body use="literal"/> > </output> > <fault name="Failure"> > <soap:fault name="Failure" use="literal"/> > </fault> > </operation> > </binding> > Now, when I use WSDL2Java to generate XMLBeans Java code for these, and try > to write a client that will send a message in this format, I write something > like this: > final CLoginDocument login = CLoginDocument.Factory.newInstance(); > login.setCLogin( "testlogin" ); > final CPasswordDocument password = > CPasswordDocument.Factory.newInstance(); > password.setCPassword( "testpassword" ); > final FServiceStub service = new FServiceStub( null, targetEndpoint ); > final FullEventUpdateDocument fullEventUpdate = > FullEventUpdateDocument.Factory.newInstance(); > fullEventUpdate.setFullEventUpdate( getSituation() ); > return service.acceptFEvent( fullEventUpdate, login, password ); > This seems reasonable, and mostly works. Except that when I look at the SOAP > output using TCPMon, the SOAP header that is included in the outgoing SOAP > message contains the CLogin element as expected, but totally omits the > CPassword element (!). I can find no reason for this. Both were passed to the > stub, and both are non-null, so both should be included in the output. > When I step through the code in the stub using a debugger, however, then the > code seems to correctly generate the header including both the login and > password, as I would expect. So this is a stereotypical "heisenbug" as per > the Jargon File: everything works fine when I run it under the debugger and > watch what is happening, but it fails when run normally. > My theory is that the debugger is calling toString() on various items such as > the SOAP envelope which is constructed to contain both the CLogin and CHeader > elements. I suspect that calling toString() in this fashion forces the > underlying OMElements to cache the results of parsing the XML, and that when > it comes time to generate the SOAP message for output, reading from this > cache works differently from parsing the header elements directly somehow. > Regardless, this seems like a pretty serious bug in Axis2: If I add multiple > header elements to a message, I expect that they all should be included in > the outgoing SOAP message, but that is not happening unless I run the program > under a debugger. The fact that this is nondeterministic hints at a caching > or multithreading bug at some level within the Axis architecture, which is > quite worrisome, since the process of formatting and sending a SOAP message > should be completely deterministic and repeatable. > Derek -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
