Migration of existing WebLogic/Oracle bug: https://bug.oraclecorp.com/pls/bug/webbug_edit.edit_info_top?rptno=10629889
Throw an exceeding stated content length exception, because the actual length of the message is more than the Content-Length value.
[How to reproduce the problem]
The test case has been attached to the issue.
1) Create a dispatch with addressing feature.
2) Create a soap message as the input argument of invokeOneWay(SOAPMessage message), and the soap message is an instance of the SAAJ which is implemented with "com.sun.xml.messaging.saaj.soap.ver1_1.Message1_1Impl" which can be imported from jar package of glassfish.jaxws.saaj.impl_18.104.22.168_2-2-5.jar.
3) Call saveChanges() method.
With debugging source code, I found that the Content-Length value of the message is saved once and never been updated afterwards (even though adding the addressing header into the message). In fact, the length of the message will increase when the message is processed with the Addressing feature processor, but Content-Length value remains the same. I found that the problems arises when encoding an XML infoset portion of the Message (from <soap:Envelope> to </soap:Envelope>) using the method of "com.sun.xml.ws.api.pipe.Codec.encode(Packet packet, OutputStream out) ".
This encode method has two kinds of situations as follows:
a) If reqHeaders contains the key of "Content-Length" and its value (which is not updated), the second input parameter of encode method will be the object of ContentLengthOutputStream. Under this circumstance, it will compare the message actual length with the value of "Content-Length" which can be got from reqHeaders. If the Content-Length value is not updated, the exception above will be thrown. And that is the fact.
b) If remove the key of "Content-Length" from reqHeaders (which should be processed within class of "com.sun.xml.ws.transport.http.client.HttpClientTransport"), the second input parameter of encode method will be the object of UnsyncByteArrayOutputStream. Under this circumstance, it will not check the message length and will not throw the exception above.
I adopt the solution of removing the key of "Content-Length" from reqHeaders.