Also, why does it add the declarations to every single nested child, and not the just the top level element?
DOMWriter given any arbitrary DOM element from the the tree should produce valid XML. i.e. it must include the NS declarations from further up if they are not defined on the element that is beeing written out.
Previous to the change to DOMWriter, the SOAP content element was beeing assigned invalid XML, which had to be corrected before the fragment was passed to JBossXB.
If NS declarations are duplicated on nested elements that would be an error. Correct is, that every XML fragment associated with a SOAPContentElement is valid, which leads to NS declarations on
#1 SOAPBodyElement for doc/lit and
#2 RPC params for rpc/lit
#3 SOAPHeader elements
The DOMWriterTestCase should comperensivly test the correct behaviour of the DOMWriter.
The XML fragment association may go away in future
http://jira.jboss.org/jira/browse/JBWS-1314 when we no longer need to pass XML fragments to JBossXB (i.e can work with DOMSource for example)
Ah, I see.
I believe the repetition was limited to namespaces defined outside of the content element. This is easy to fix nonetheless.
There is also a problem with qname values. Since only the namespaces that are actually used are declared when needed, and since only elements and attributes are looked at, there is the possibility that a qname element or a qname attribute will not have a defined namespace. JBWS-1303 demonstrates one example of this problem
Further, it is not possible to know if Text nodes or attribute values refer to a qname unless DOMWriter has knowledge of the schema (which is impractical for its purpose). Therefore, the only way to guarantee correct XML is to always copy all namespaces from all parent nodes to the start of a fragment (although using proper scoping).
I implemented this approach in my local tree, but unfortunately the extra namespace noise breaks 20 something tests. This is because the SOAP content element remains in string mode, thus the message is permanently altered. Since this is an undesirable side effect, and since the namespace modified string is only necessary when passing a fragment to an unmarshalling component, the xml string should really be a transient value.
Therefore I see two possible solutions.
1) Modify SOAPContentElement to no longer persist the xml string, and to only use it when unmarshalling is invoked. Also modify SAAJPayloadBuilder to use DOM.
2) Wait for the DOM optimiations (JBWS-1314), and then modify our processing phase to do temporary alterations on the Element before passing to the unmarshaller.
Due to our heavy load, and our tight release schedule, I think we should go with 2. We can then just add workarounds on an as needed basis.
Greetings! I'm posting this reply, to let you know that this issue arises when implementing WS with delphi clients. Delphi is somehow always using default namespaces and within that type of xml formulation, simple method parameters normally defined as:
<q0:getUserByCredentials> <arg0 xmlns="">kumy</arg0> <arg1 xmlns="">mah</arg1> <q:/getUserByCredentials>
are transmited in this form from delphi:
<getUserByCredentials xmlns="some_namespace"> <arg0 xmlns="">k</arg0> <arg1 xmlns="">m</arg1> </getUserByCredentials>
After parsing the last case, these parameters(arg0 and arg1) appear empty. Is there any recomendation how to work around this issue for now?
I'm sincerely sorry. The examples provided are somehow not complete and right. I'm posting them again for proper ilustration:
Java client would send a request like this:
<q0:getUserByCredentials> <arg0>k</arg0> <arg1>m</arg1> <q0:/getUserByCredentials>
Delphi client would send a request like this:
<getUserByCredentials xmlns="somens"> <arg0>k</arg0> <arg1>m</arg1> </getUserByCredentials>
Could you move that topic to the user forum?
And please attach a complete request including the server log.