Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
Tomas-Kraus opened this issue Apr 11, 2012 · 7 comments

Comments

@Tomas-Kraus
Copy link
Member

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]

@Tomas-Kraus
Copy link
Member Author

@glassfishrobot Commented
Reported by bthalmayr

@Tomas-Kraus
Copy link
Member Author

@glassfishrobot Commented
File: SOAPMessageSampleFailing.java
Attached By: bthalmayr

@Tomas-Kraus
Copy link
Member Author

@glassfishrobot Commented
File: SOAPMessageSampleWorking.java
Attached By: bthalmayr

@Tomas-Kraus
Copy link
Member Author

@glassfishrobot Commented
Was assigned to gagordon

@Tomas-Kraus
Copy link
Member Author

@glassfishrobot Commented
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.

@Tomas-Kraus
Copy link
Member Author

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

@Tomas-Kraus
Copy link
Member Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants