axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eran Chinthaka (JIRA)" <j...@apache.org>
Subject [jira] Commented: (AXIS2-928) Not all added header elements are included in outgoing SOAP header unless run under debugger - bug in OMElement caching?
Date Tue, 12 Sep 2006 23:38:22 GMT
    [ http://issues.apache.org/jira/browse/AXIS2-928?page=comments#action_12434319 ] 
            
Eran Chinthaka commented on AXIS2-928:
--------------------------------------

Yes, I agree. These sorts of comments comes when staying awake middle of the night. Sorry.
:(

> 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: Blocker
>
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org


Mime
View raw message