[jira] Updated: (AXIS-1246) AttachmentsImpl.getAttachmentCount() may report 0 attachments for message that has >0 attachments

[ji...@apache.org]

The following issue has been updated:

    Updater: Tom Nelson (mailto:tom.nelson@raba.com)
       Date: Wed, 3 Mar 2004 12:17 PM
    Changes:
             Attachment changed to axis_patch_attachmentsimpl
    ---------------------------------------------------------------------
For a full history of the issue, see:

  http://nagoya.apache.org/jira/secure/ViewIssue.jspa?key=AXIS-1246&page=history

---------------------------------------------------------------------
View the issue:
  http://nagoya.apache.org/jira/secure/ViewIssue.jspa?key=AXIS-1246

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: AXIS-1246
    Summary: AttachmentsImpl.getAttachmentCount() may report 0 attachments for message that has >0 attachments
       Type: Bug

     Status: Unassigned
   Priority: Major

    Project: Axis
 Components: 
             Basic Architecture
   Versions:
             1.2 Alpha

   Assignee: 
   Reporter: Tom Nelson

    Created: Wed, 3 Mar 2004 12:16 PM
    Updated: Wed, 3 Mar 2004 12:17 PM

Description:
When sending an org.apache.axis.Message with a javax.activation.DataHandler
attachment, the org.apache.axis.attachments.AttachmentsImpl.createAttachment()
 call is deferred until the attachments are
first serialized. The problem is that, when
org.apache.axis.Message.writeTo() is first called, it determines if attachments
exist by calling Attachments.getAttachmentCount(), and comparing to zero.
Unfortunately, at that time, the attachments have not yet been added.

I propose that the org.apache.axis.attachments.AttachmentsImpl.getAttachmentCount() 
method be modified so that it indirectly causes the attachments to be added. The
modification would follow the example in several other AttachmentsImpl methods 
(getContentLength(), writeContentToStream(), getContentType()) where the 
multiref object is lazily created, and soapPart.getAsString() is called as an
argument to MimeUtils.createMP().

This problem shows up when using JMS transport if the log level is
set higher than debug because a debug call causes the message to be serialized 
once to a log file (thus adding the attachments) before the message is serialized
and sent to the recipient. 
In the http case, I believe that this problem is masked because of a
call to 'getContentLength()' prior to the Message.writeTo call. As noted above, the 
getContentLength() call indirectly causes the attachments to be added.

I will attach a patch file for the AttachmentsImpl class

Tom Nelson
RABA Techmologies


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira