DO NOT REPLY [Bug 22980] New: - Header elements defining their own default namespace cause problems

[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=22980>.
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=22980

Header elements defining their own default namespace cause problems

           Summary: Header elements defining their own default namespace
                    cause problems
           Product: Axis
           Version: 1.1
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Serialization/Deserialization
        AssignedTo: axis-dev@ws.apache.org
        ReportedBy: colin.taylor@prolog.uk.com


Headers elements that define their own default namespace cause problems if 
they are followed by more headers. The header immediately following the one 
defining its own default namespace will lose any explicit namespace. For 
example, a message such as:

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <soapenv:Header>
     <TrackingHeader xmlns="http://testns.org/test">1234</TrackingHeader>
     <ns1:Security soapenv:mustUnderstand="0" xmlns:ns1="http://schemas.xmls
oap.org/ws/2002/07/secext">
         <ns1:UsernameToken>
            <ns1:Username xsi:type="xsd:string">foobar</ns1:Username>
            <ns1:Password xsi:type="xsd:string">wibble</ns1:Password>
         </ns1:UsernameToken>
      </ns1:Security>
   </soapenv:Header>
   <soapenv:Body>
         <EchoString>asdadsf</EchoString>
   </soapenv:Body>
</soapenv:Envelope>

will cause problems as the namespace of the Security element will be lost. 
This can be seen by feeding the above message into any old service and logging 
the inbound message using the LogHandler -- the message logged will not match 
that given above - the Security element will have lost its namespace.