Repository navigation
Explain why LoggingSOAPHandler calls getMessage() - #510
Open
tonygermano wants to merge 1 commit into
Open
tonygermano wants to merge 1 commit into
tonygermano wants to merge 1 commit into
Conversation
LoggingSOAPHandler.handleMessage() calls smc.getMessage() and ignores the result, so the call looks safe to remove. It isn't. In the JAX-WS RI, getMessage() converts the message to an in-memory SAAJ copy, and once the handler chain finishes, that copy replaces the original message. Two behaviors depend on this. Converting to SAAJ parses the entire request. Without the call, JAX-WS reads only as far as it needs to bind the parameters, so a request with malformed XML after the payload element is processed and answered with 200 instead of being rejected with a fault. Comparing the call present and removed on JDK 17: - unclosed element after the payload: 500 / 200 - mismatched tags after the payload: 500 / 200 - markup after </Envelope>: 500 / 200 - truncated right after the payload: 500 / 500 - valid request: 200 / 200 Responses are serialized from the SAAJ copy. Without the call, every response would lose the empty SOAP-ENV:Header, the extra xmlns:SOAP-ENV declaration and the xmlns="" on the return element. The XML means the same thing, but clients that compare raw text would see a difference. The channel receives the same payload from a valid request either way, and mustUnderstand faults and faults raised by the service are unchanged, because handleFault() doesn't call getMessage(). Removing the call would save building a DOM for each request and response. But keeping the current strictness would need another full parse, which gives most of that saving back. Found while looking into OpenIntegrationEngine#509. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Tony Germano <tony@germano.name>
tonygermano
requested review from
a team,
NicoPiel,
gibson9583,
jonbartels,
kayyagari,
kpalang,
mgaffigan and
ssrowe
October 23, 2026 14:19
mgaffigan
approved these changes
Oct 23, 2026
pacmano1
approved these changes
Oct 23, 2026
kryskool
approved these changes
Oct 24, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
LoggingSOAPHandler.handleMessage() calls smc.getMessage() and ignores the result, so the call looks safe to remove. It isn't. In the JAX-WS RI, getMessage() converts the message to an in-memory SAAJ copy, and once the handler chain finishes, that copy replaces the original message. Two behaviors depend on this.
Converting to SAAJ parses the entire request. Without the call, JAX-WS reads only as far as it needs to bind the parameters, so a request with malformed XML after the payload element is processed and answered with 200 instead of being rejected with a fault. Comparing the call present and removed on JDK 17:
Responses are serialized from the SAAJ copy. Without the call, every response would lose the empty SOAP-ENV:Header, the extra xmlns:SOAP-ENV declaration and the xmlns="" on the return element. The XML means the same thing, but clients that compare raw text would see a difference.
The channel receives the same payload from a valid request either way, and mustUnderstand faults and faults raised by the service are unchanged, because handleFault() doesn't call getMessage().
Removing the call would save building a DOM for each request and response. But keeping the current strictness would need another full parse, which gives most of that saving back.
Found while looking into #509.
Assisted-by: Claude:claude-opus-5-5