writeTo(OuptutStream) does not 'save' the message before writing it out to the stream

[glassfishrobot]

According to the java-doc 'http://docs.oracle.com/javase/7/docs/api/javax/xml/soap/SOAPMessage.html#saveChanges()' 'writeTo(OutputStream)' should call this message automatically. But if a message is changed 'writeTo(OutputStream)' has no clue about it so it does not call 'saveChanges()'. I used 'SOAPProcessorSample' as a basis from the 'soapnode' sample included in the SAAJ samples to show it.

Output when running the ant target ....

runtest:
[java] final message :
[java] <env:Envelope xmlns:env='http://schemas.xmlsoap.org/soap/envelope/'>env:Header<abc:Extension1 xmlns:abc='http://example.org/2001/06/ext' env:actor='http://schemas.xmlsoap.org/soap/actor/next' env:mustUnderstand='1'/><def:Extension2 xmlns:def='http://example.com/stuff' env:mustUnderstand="1"/></env:Header>env:Body/</env:Envelope>
[java] final message ends here.
[java] final message :
[java] <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">env:Header<abc:Extension1 xmlns:abc="http://example.org/2001/06/ext" env:actor="http://schemas.xmlsoap.org/soap/actor/next" env:mustUnderstand="1"/><def:Extension2 xmlns:def="http://example.com/stuff" env:mustUnderstand="1"/></env:Header><env:Body wsu:Id="1234566901234"/></env:Envelope>
[java] final message ends here.

BUILD SUCCESSFUL

Environment

Metro 2.2, using SAAJ 1.3.18, Oracle HotSpot VM 1.6.0_29,

Affected Versions

[1.3.15]

[glassfishrobot]

Reported by bthalmayr

[glassfishrobot]

File: SOAPMessageSampleFailing.java
Attached By: bthalmayr

[glassfishrobot]

File: SOAPMessageSampleWorking.java
Attached By: bthalmayr

[glassfishrobot]

Was assigned to gagordon

[glassfishrobot]

gagordon said:
The spec and javadocs appear to be outdated/impractical and we will try to clarify/change the spec for the next major release of SAAJ. As of SAAJ 1.1 the SOAP message elements are DOM nodes as well, and tracking all changes that occur due to DOM API invocation would require subclassing every DOM method, including any DOM implementation-specific methods that might change the SOAPMessage. Another alternative is to rewrite SAAJ-RI to implement the DOM interfaces and delegate to a concrete implementation, but this is a major rewrite that won't be attempted now. In any case, we will keep this bug as an improvement/suggestion and revisit the issue in the next major revision.

In addition to DOM issues, tracking changes inside a DataHandler for an AttachmentPart has never been feasible even before SAAJ 1.1, for example, we have know way of knowing whether a DataHandler would always produce the same attachment bytes, and this could also lead to an incorrect dirty state. For example, there could be a time stamp in the data produced that would cause the wire bytes to differ.

The actual current SAAJ-RI behavior is that the message is initially in a "dirty" state until writeTo() is called, which has the side effect of marking the message "clean". Most changes after that will not be noted in the message object, but calling saveChanges() will reset the dirty flag. Requiring the user to call saveChanges() when making a modification after writeTo()is invoked doesn't seem all that problematic if the documentation is clear.

I would prefer to see the javadoc for SOAPMessage.saveChanges()read something as follows:

"Updates this SOAPMessage object with all the changes that have been made to it. [Delete this]: (This method is called automatically when writeTo(OutputStream) is called. However, i)If changes are made to a message that was received or to one on which writeTo() has already been invoked [Delete]: (that has already been sent), the method saveChanges needs to be called explicitly in order to save the changes.

Note issue 69 that you filed is really the same problem, so it will be marked as a dup.

[glassfishrobot]

This issue was imported from java.net JIRA SAAJ-68