[ http://issues.apache.org/jira/browse/AXIS2-928?page=all ]
Deepal Jayasinghe reassigned AXIS2-928:
---------------------------------------
Assignee: Eran Chinthaka
> 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
> Assigned To: Eran Chinthaka
> 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]
