DO NOT REPLY [Bug 26104] New: - Serialization of headers in a SOAP request fails if debugs are enabled

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26104>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26104

Serialization of headers in a SOAP request fails if debugs are enabled

           Summary: Serialization of headers in a SOAP request fails if
                    debugs are enabled
           Product: Axis
           Version: current (nightly)
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Major
          Priority: Other
         Component: Serialization/Deserialization
        AssignedTo: axis-dev@ws.apache.org
        ReportedBy: tkoponen@iki.fi


The org.apache.axis.client.Call dumps the SOAP request to be sent to the logs,
if the debug level has been enabled.  In other words, the SOAP request must be
serialized (for the first time).   The debug dump occurs approximately on line
2655 in Call.java by the way.  However, the actual transport (HTTP in this case)
also serializes the SOAP request (now for the second time during a single SOAP
call).  Unfortunately, it seems that only the first serialization produces a
legitimate SOAP request; in the second run, user specified attributes inside
SOAP headers get added _twice_ to the produced XML! For example:

<soapenv:Header>
  <ns1:HeaderXYZ soapenv:actor="http://schemas.xmlsoap.org/soap/actor/next" 
soapenv:mustUnderstand="0" MyError="false" MyError="false"  <-- twice!
xmlns:ns1="http://foobar.org/foo#">foo
  </ns1:HeaderXYZ>
</soapenv:Header>

A quick look to the code suggests that
org.apache.axis.encoding.ser.BeanSerializer's getObjectAttributes() modifies the
Attributes instance serialize() gets by adding the attributes of the value
object there _regardless_ whether the attributes are already inside the
Attributes instance.  Moreover, the Attributes instance is the very same in both
serialization runs, as it's stored into the same MessageElement instance. As a
result, only the first serialization results in a valid output.

CVS snapshot checked out on 2004/01/13 was used.