[
http://issues.apache.org/jira/browse/AXIS-1997?page=comments#action_66577 ]
Jason Sweeney commented on AXIS-1997:
-------------------------------------
I subsequently found that the same patch had to be applied to the writeTo()
method of the org.apache.axis.Message class.
Could you please complete the patch by adding the following (or its functional
equivalent) to the Message class.
public void writeTo(java.io.OutputStream os) throws SOAPException,
IOException {
//Do it the old fashion way.
>>> // When service that explicitly do not use attachments attempt to
>>> return large response
>>> // documents, the call to the getAttachmentCount() method forces a
>>> -useless- serialization
>>> // to a String instance causing out of memory errors. This temporary
>>> fix has been submitted
>>> // to the Axis project as issue AXIS-1997 for inclusion in the next
>>> version of the product.
>>> // The fix itself is similar to the code present in this method in the
>>> 1.1 version.
>>> // See: http://issues.apache.org/jira/browse/AXIS-1997
>>>
>>> // Determine the attachment send type of the current service
>>> int sendType = Attachments.SEND_TYPE_NOTSET;
>>> if ((msgContext != null) && (msgContext.getService() != null)) {
>>> sendType = msgContext.getService().getSendType();
>>> }
>>>
>>> // Only request the content type of the attachments if the service
>>> allows such constructs
>>> if (sendType == Attachments.SEND_TYPE_NONE || mAttachments == null
>>> || 0 == mAttachments.getAttachmentCount()) {
try {
String charEncoding = XMLUtils.getEncoding(this, msgContext);;
mSOAPPart.setEncoding(charEncoding);
mSOAPPart.writeTo(os);
} catch (java.io.IOException e) {
log.error(Messages.getMessage("javaIOException00"), e);
}
} else {
try {
mAttachments.writeContentToStream(os);
} catch (java.lang.Exception e) {
log.error(Messages.getMessage("exception00"), e);
}
}
}
> Regression causing out-of-memory errors for services without attachments
> returning large response messages
> ----------------------------------------------------------------------------------------------------------
>
> Key: AXIS-1997
> URL: http://issues.apache.org/jira/browse/AXIS-1997
> Project: Axis
> Type: Bug
> Components: Serialization/Deserialization
> Versions: 1.2
> Environment: Irrelevant to issue at hand
> Reporter: Jason Sweeney
>
> In version 1.1, specifying a value of "none" to the attachment attribute of a
> service in the deployment description file ensured that the response message
> would be directly serialized to the HTTP response stream (for the HTTP
> transport type).
> This has been broken in the 1.2 version by the addition of the following
> lines in the org.apache.axis.attachments.AttachmentsImpl.getAttachmentCount()
> method:
> // force a serialization of the message so that
> // any attachments will be added
> soapPart.saveChanges();
> This method is called from the org.apache.axis.Message.getContentType()
> method in the following section:
> if (mAttachments != null && 0 != mAttachments.getAttachmentCount()) {
> ret = mAttachments.getContentType();
> }
> In order to preserve the support of large response message for services that
> explictly do not allow attachments, the following code (or its functional
> equivalent) should be added:
>
> >> int sendType = Attachments.SEND_TYPE_NOTSET;
> >> if ((msgContext != null) && (msgContext.getService() != null)) {
> >> sendType = msgContext.getService().getSendType();
> >> }
> >> if (sendType != Attachments.SEND_TYPE_NONE) {
> if (mAttachments != null && 0 !=
> mAttachments.getAttachmentCount()) {
> ret = mAttachments.getContentType();
> }
> >> }
> NOTE: Detection of the send type was already present in the 1.1 version of
> this method.
> There is no functional issue with this modification since the service
> explicitly declares itself free of attachments, so the attachment count will
> necessarily be zero. This low-cost extra validation allows for an entire
> realm of services to be supported by Axis (massive exports of data) in a
> seamless way immediately in 1.2.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
